深层继承层次结构 - 坏主意？

Question

希望大师可以发光.非常高的概述是我不是编码的初学者,但仍然是OOP的新手.这组消息类是我们正在编写的大型仿真应用程序的核心,我不想愚蠢地做 - 这个接口将应用程序减少了一半,从音序器到执行器,反之亦然.

我的问题是,这种深层次的继承层次结构是否是一个坏主意(图像尚未充实,最终可能会深入5或6).这与某些子类只与其父类具有定向关联而不是继承相反.

我已经读过深层继承层次结构并不是一个好主意,并且如果一个子类继承只是为了拥有父数据,那么你应该简单地将父项作为数据包含在子项中,但是我很难时间缠绕我的脑袋为什么.如果我决定制作一个7-deep的继承层次结构或类似的东西,那将会发生什么坏事呢？很明显,性能受到了很小的影响,并且层次结构顶部的变化会在整个应用程序中产生巨大的涟漪,但除此之外我没有看到问题.除此之外,我对性能方面的微小差异一点也不关心.

(奖励问题:是否有一个现成的包处理这种东西？我们处理了大部分低级物理模拟,但是我们必须编写的排序程序.我只是怀疑这个我所提出的内容与我之前的10,000个模拟开发人员非常相似.)

(奖金问题#2:任何模拟系统和OOP编程的大师,都不会讨厌生活在洛杉矶？我们正在招聘.)

Answer 1

如果子类继承只是为了拥有父数据

这是一个坏主意.有这样的理解,你将基类定义为一组(具体)类将要遵守的最通用的契约.这通常意味着您的合同是关于行为而不是实施.

如果我决定制作一个7-deep的继承层次结构或类似的东西,那将会发生什么坏事呢？

这里的主要问题是世俗的:

• 脆弱的基类(对基础的更改是派生的噩梦)
• 耦合增加(基类过多导致紧耦合)
• 封装减弱
• 测试问题(叶级重写方法不能仅仅被测试以正确地再现最终用户行为,因为这里和那里存在多个链式调用)
• 维护(来自强耦合)

(你们很多人都想仔细研究为什么阿达不受欢迎,特别是第6项第6段).

是否有现成的包处理这种东西？

我不确定你在寻找什么,但如果你正在寻找一个自动化的层次结构简化器,那我就不知道了.此外,如果这样的包存在,它将高度依赖于您选择的语言,而您没有提到.

请注意,大多数情况下,可以通过查看聚合或特征或依赖注入等替代方案来解决此类问题.这些是设计时间问题,通常(IMO)最好在白板上解决,而不是编译器和数百万LOC.

Answer 2

很晚才看到这个问题，但我对此有很多想法，并且被深深的继承层次结构所困扰。它们不好的原因之一是，当你专门化许多子类时，你将不可避免地得到错误的分类。然而，一旦你有了适当的类结构，就很难改变，因为这样做会破坏客户端代码。

我在这里写了关于这个的博客。