多少级别的继承

Cor*_*ius 23 java inheritance frameworks

对于框架和指南的最大深度,是否有关于何时使用多级继承或在单个类中加入它们的最佳实践?

一些在Java世界中运行良好的既定实践/示例的引用在答案中会很好,因为这是从围绕Java的社区和框架的角度来看.

And*_*s_D 22

您可能正在寻找一个很好的规则,例如"不超过5级继承"但我真的怀疑有这样的规则.对象通常模拟现实世界的实体,所有这些实体的社区从未就规则达成一致(据我所知)......

一个"最佳实践"绝对是:赞成合成而不是继承.遵循本指南:定义一个没有其他超类的接口和实现.所有常见的领域和方法都伴随着行为和策略

另一方面,我们有时会模拟真实世界实体或结构,这些实体或结构已经具有深层次的实体.动物的分类是一个例子或代数结构.建模这种现有结构的框架需要深层次的层次结构,因为它应该跟随现实世界才能理解.

  • 当然,动物分类存在遗传结构的问题. (9认同)
  • 我讨厌看到*赞成组合而不是继承*在任何地方,超出上下文.你使用重要的组合和重要的继承.真正的规则应该是*不要使用继承作为代码共享机制.* (5认同)

Pad*_*ddy 6

我认为,从维护的角度来看,尽可能浅的继承层次结构是正确的选择。通过多个层次结构跟踪错误,然后必须弄清楚应该在哪一层修复这些错误可能是一件棘手的事情。

  • 我会以完全相反的方式争论:通过将类折叠成更少、更大的类,你会使调试变得更加困难。 (6认同)
  • @aioobe - 这是事实,但也有可能走得太远,将事物分割得太远,其中组合比继承更有利。我正在研究一些发生这种情况的复杂层次结构...... (4认同)

dar*_*ioo 6

从我所看到的(注意:这不是官方意见,只是我的观察),3-4是一个合理的最大值.

另外,请记住Effective Java的一个重要部分:

赞成合成而不是继承


aio*_*obe 5

在我看来,每个派生类都是"它自己的一个类",这个类的客户端,包括子类,一般不应该打扰或感兴趣,这个类和Object类之间有多少个类.

因此,我的回答是:不,让层次结构尽可能地深入,只要它有意义/似乎是合乎逻辑的.不要让层次结构深度影响是否要折叠两个类的决定.由于每个子类都是对它的基类的改进,我的经验表明,深度超过5或6个类很少有意义.


需要明确的是:正如其他人所指出的,你应该赞成合成而不是继承.然而,对我而言,这似乎回答了一个稍微不同的问题.


根据这篇文章,标准Java API的最大深度为9.

  • 这是完全错误的.继承是众所周知的复杂因素. (4认同)
  • 你是说通过折叠课程得到一个不太复杂的程序? (4认同)
  • @Reza任何概念都可以带到极端,我们不需要MSDN告诉我们.这就是为什么**aioobe**说*只要它有意义/似乎合乎逻辑*. (4认同)
  • 任何代码复杂度指标都具有类继承深度的因素.根据MS MSDN,层次越深,理解特定方法和字段定义或/和重新定义的位置就越困难 (2认同)
  • @Reza另外,如果你在强调维护方面的技术难题,那么任何体面的IDE都会向你展示重新定义方法的子类. (2认同)
  • @Nikita IDE 功能与代码复杂性无关。我们不根据 IDE 功能来衡量代码复杂性,也不将 IDE 作为架构考虑因素来设计系统 (2认同)