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

希望一位大师能给我们一些启示。非常高的概述是，我不是编码新手，但仍然是OOP新手。这组消息类是我们正在编写的一个大型模拟应用程序的核心，我不想做得太愚蠢——这个接口将应用程序从sequencer到executer一分为二，反之亦然

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

我已经读到，深层继承层次结构不是一个好主意，如果子类继承只是为了拥有父类的数据，那么您应该简单地将父类作为数据包含在子类中，但我很难理解为什么。如果我决定创建一个7层的继承层次结构或类似的东西，会发生什么坏事？很明显，这会对性能造成小的影响，在层次结构的顶端进行更改会在整个应用程序中产生巨大的涟漪，但除此之外，我看不出有什么问题。除此之外，我不在乎表现上的细微差别

（附加问题：是否有现成的软件包来处理这类事情？我们已经处理了大部分低级别的物理模拟，但我们将不得不编写测序程序。我只是怀疑我所做的与之前10000名模拟开发人员所做的非常相似。）

（额外问题#2：有谁同时精通模拟系统和面向对象编程，不讨厌住在洛杉矶？我们正在招聘。）

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

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

如果我决定创建一个7层的继承层次结构或类似的东西，会发生什么坏事

这里的主要问题很平常：

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

（你们很多人都想仔细阅读这篇文章，特别是第6段第6项。）

有现成的包装来处理这种东西吗

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

---

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

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

---

我在博客上写了这篇文章。

我不了解细节，但布局在我看来相当混乱。至于q。我也是，但你7年前没问我。