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

Question

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

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

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

（额外问题：是否有一个现成的软件包可以处理这类事情？我们已经处理了大部分低级物理模拟，但是我们必须编写测序程序。我只是有这个怀疑我所阐述的内容与我之前的 10,000 名模拟开发人员所做的非常相似。）

Answer 1

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

这是一个坏主意。有一种理解是，您将基类定义为一组（具体）类将遵守的最通用的契约。这通常意味着您的合同是关于行为而不是实施。

如果我决定将继承层次结构设置为 7 深或类似的东西，我们会发生什么不好的事情？

这里的主要问题很平常：

• 脆弱的基类（对基类的更改对于派生类来说是一场噩梦）
• 增加耦合（基类太多会导致紧密耦合）
• 封装变弱
• 测试问题（由于到处都有多个链式调用，不能仅仅测试叶级重写方法来正确地重现最终用户行为）
• 维护（来自强耦合）

（你们很多人想仔细阅读这篇关于 为什么 Ada 不受欢迎的论文，特别是第 6 条第 6 段。）

有现成的软件包可以处理这类事情吗？

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

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

Answer 2

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

我在博客这里。

Answer 3

老问题，但软件开发中的活跃问题，想添加可能有帮助的意见。

当您使用 DI 接触基类时，无法估计维护开销。这是最近影响我们的 3 级深度继承结构的一个主要缺点。 另外，如果您的基础是一个模板，那么如果您有太多子级且在 3 个级别中只有 1 个派生父级，则预计会违反 SOL(I)(D)。

一般来说，为了访问数据，我会选择适当的设计模式，或者在不违反 SOLID 的情况下传递数据指针。根据您只是阅读还是写作，我还会避免使用 getter 和 setter 以避免“准类”。默认子项受到“保护”的情况很少见，我认为这种情况下的结构可能存在设计缺陷。