自己太菜了，求问，如何看懂有非常多继承的代码？

• 主 資深大佬 : fakerw

  ？

• 資深大佬 : chendy

  如果真的要知道实现方式，可能只能这样了……
  更多的时候看一眼调用关系知道个大概就行了

• 資深大佬 : fucUup

  晕啥，Linux 21 万个类，查字典即可

• 資深大佬 : fucUup

  不要妄想 1 个月练成葵花宝典，至少 20 年

• 資深大佬 : Justin13

  先理解设计，再理解流程，再看文件结构，最后看代码。

• 資深大佬 : nuk

  运行时 debug

• 資深大佬 : pastgift

  有时候其实就是过度设计，一堆没意义的继承导致代码难读，不是你的问题
  根据我的经验，好的代码思路清晰，继承多少关系其实不大，你 get 到作者的的点很快就能推测出整体结构。而不好的代码谁来都皱眉头。

• 資深大佬 : laminux29

  用 UML 工具，把这些代码转换为图，一目了然。

• 資深大佬 : sam014

  @fucUup 20 年为什么要来练葵花宝典，你在欺负前端，哈哈哈

• 資深大佬 : hello2060

  点击函数名，跳到定义不就行了。父类的非 private 函数子类也可以用，这个很好理解啊。

  所以你迷在哪里？

• 資深大佬 : Skmgo

  @laminux29 UML 工具推荐几个?

• 資深大佬 : anthow

  多 debug

• 資深大佬 : oatw

  组合优于继承。

  开源项目的流行度和代码质量不一定成正比，过多继承的建议先绕过。

• 資深大佬 : cczeng

  合成聚合复用原则- 多使用组合，而不是多使用继承

• 資深大佬 : cczeng

  如果是已有项目，那就只能这样。 #5 说的没错。

• 資深大佬 : James369

  @fucUup #4 不好意思，程序员的职业生涯没有 20 年，啊哈哈

• 資深大佬 : jadeborner

  你说的是 ES6 的继承？

• 資深大佬 : aninchiron

  所以我喜欢函数式编程

• 資深大佬 : Lemeng

  不是大问题，debug

• 資深大佬 : way2explore2

  @fucUup xian zi gong a

• 資深大佬 : lewis89

  一般超过三层 就没人摸得着头脑了，Spring 里面的设计 至少超过 7 层.. 类图绕得人头大，不过你可以先看下 架构 overview

• 資深大佬 : chesterzzy

  Sourcetrail 等类似的代码查看工具，应该会有一定的帮助

• 資深大佬 : yazoox

  别总想着“继承“。如果可能，应该可以尽可能少的使用继承。等你代码写多了，就能体会到，很多时候，”不继承“比”继承“要好。

  design principle 里面有一条就是，composition over inheritance

• 資深大佬 : soulmt

  用 xmind 梳理调用流程和 class 之间的继承关系，再标注一下各个类自带的函数以及做什么的就好了，光看的话，确实很难办

• 資深大佬 : soulmt

  @yazoox 写业务能不继承就不要继承，写框架还是比较推荐的。

• 資深大佬 : acmore

  难道是在看 Spring 源码么，那一大堆 BeanFactory & ApplicationContext 的继承确实挺恶心人的。
  而且这一堆继承与其说是基于设计，倒不如说是基于历史的，确实让人头大。

• 資深大佬 : taogen

  做过一个玩具项目，可以根据 Java doc 文档转换为 plantuml 类图。有兴趣的可以看看。
  https://github.com/tagnja/plantuml-generator

• 資深大佬 : tmackan

  idea 可以查看源码的 uml 图的，右键点击 Diagrams

• 資深大佬 : taogen

  @tmackan #28
  之前没发现这功能，这个功能挺不错的。但是好像只能看一个类的上级继承类，不能看下级子类，也就是不能看涉及一个类的完整继承链。

• 資深大佬 : happinessnch

  继承不仅仅是代码复用，也是 OOP 设计的一个方法，继承类与父类要存在 is a 的关系，所以先理解基类，由顶向下的理解，再去研究某个类的某个方法具体实现，先了解一下 OO 的设计原则和基础。

• 資深大佬 : index

  用好 ide 快捷键，在看类关系，子类，接口实现等，都有快捷键，能很大程度减少视线迷路的概率

• 資深大佬 : abersheeran

  继承太多，往往是代码太烂。

• 資深大佬 : johnsona

  理解核心的代码即可 搞懂全部完完全全没必要

• 資深大佬 : Rocketer

  继承是为了复用，所以父类、爷类、祖宗类都应该当黑盒使，你就只关注你用到的那一层就行。只要不是那种方法名看不懂要做什么的垃圾代码，就没必要翻到上层去看它。

• 資深大佬 : tmackan

  @taogen 可以的 你捣鼓下～

• 資深大佬 : tmackan

  @taogen 右键选择 implement 或者查看 parent 就可以查看 上下游了，说实话 java 源码看起来很费劲

• 資深大佬 : whoim

  个人觉得，没必要每一个类每一个函数都要知道是干什么的，只要知道整体逻辑就可以！否则只会陷入各种细节中！

• 資深大佬 : fiveelementgid

  不知道，C#不支持多重继承
  Inherite: only one class and multiple interfaces

• 資深大佬 : auh

  小菜鸡，闲谈两句，篇幅不大。主看看。小菜鸡害羞，其他人忽略。https://player.fanlushuai.win/coder/%E7%9C%8B%E6%87%82%E8%AE%BE%E8%AE%A1/

• 資深大佬 : bruce0

  @pastgift 我也同意,好的代码不是说用了多少种设计模式。设计的多么优雅，而是能简单易懂，让人一看就明白

• 資深大佬 : toomlo

  @pastgift #7 golang 吗,嘻嘻

• 資深大佬 : laminux29

  @Skmgo EA 。全称 Enterprise Architect 。

• 資深大佬 : LessonOne

  @Justin13 大多数人都是先写代码搞业务流程 才慢慢 总结设计然后有自己的一套设计模式 新手 只能先理解 逻辑

• 資深大佬 : aguesuka

  ctrl+h ctrl+alt+shift+u

• 資深大佬 : jones2000

  拿张纸和笔， 把类和继承关系简单画下。 对于某一个函数功能，用单点调试的方法，一步一步跟进去。 光看代码没用的， 看半天就晕了。

• 資深大佬 : hitmanx

  如果还有懂这个代码的老人在的话，让他给你讲一讲中间的设计想法和慢慢的变迁比你自己看效率要高很多。

  代码都是从简单慢慢变得复杂的，可能因为新需求或者是一些边缘情况。而一个新人在不了解这个背景和历史的情况下，看得似懂非懂的再正常不过了。如果加上是一堆烂代码的话，看得头大也很正常。

  如果在没有老人或者只能自助的情况下可以看代码的 commit history （如果有的话），并且有对应的 bug 或者文字描述或者邮件讨论的话就更佳了。如果都没有，那只能自己去硬啃了^_^

• 資深大佬 : THESDZ

  继承或者接口这类代码,如果自下往上看,是真的很难懂,你要先看架构图(设计图之类的),自上往下推才能比较好懂…

• 資深大佬 : trumpasjokerA

  用 idea 把类结构图打出来，先单个研究明白，自顶向下看好理解一些