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

Question

希望高手能解惑。非常高的概述是我不是编码的初学者，但对 OOP 还是新手。这组消息类是我们正在编写的一个大型模拟应用程序的核心，我不想愚蠢地这样做——这个接口(interface)将应用程序切成两半，从定序器到执行器，反之亦然。

我的问题是拥有这么深的继承层次结构是否是一个坏主意(图像尚未充实，最终可能会达到 5 或 6 深)。这与让某些子类与其父类直接关联而不是继承相反。

我读过深继承层次结构不是一个好主意，如果子类继承只是为了拥有父级的数据，那么您应该简单地将父级作为数据包含在子级中，但我很难时间围绕为什么。如果我决定将继承层次结构设为 7 深或类似的东西，将会发生什么坏事？很明显，性能受到了很小的影响，并且层次结构顶部的更改将在整个应用程序中产生巨大的影响，但除此之外我没有看到任何问题。除此之外，我不太关心性能上的细微差别。



(额外的问题:是否有现成的包可以处理这种东西？我们处理了大部分低级物理模拟，但是我们将不得不编写排序程序。我只是怀疑我所列出的内容与我之前大约 10,000 名模拟开发人员所做的非常相似。)

(奖励问题 #2:任何同时掌握模拟系统和 OOP 编程的大师，都不会讨厌住在洛杉矶？我们正在招聘。)

Answer 1

that if a child class is inheriting simply to have the parent's data

这是一个坏主意。有这样的理解，您将基类定义为一组(具体)类将遵守的最通用的契约(Contract)。这通常意味着您的契约(Contract)是关于行为而不是实现的。

What bad thing is going to happen to us if I decided to make an inheritance hierarchy 7-deep or something like that?

这里的主要问题是平凡的:

脆弱的基类(对基类的更改对于派生类来说是一场噩梦)

耦合增加(基类过多会导致紧耦合)

封装减弱

测试问题(由于这里和那里的多个链接调用，不能仅仅测试叶级覆盖方法以始终正确地重现最终用户行为)

维护(来自强耦合)

(你们很多人都想在 Why Ada isn't popular 上仔细阅读这篇论文，特别是第 6 条第 6 段。)

Is there an off-the-shelf package that handles this kind of stuff?

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

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