希望高手能指点迷津。非常高的概述是，我不是编码初学者，但对 OOP 仍然是新手。这组消息类是我们正在编写的大型模拟应用程序的核心，我不想愚蠢地这样做——这个接口将应用程序从定序器到执行器切成两半，反之亦然。
我的问题是，拥有这么深的继承层次结构是否是一个坏主意（图像尚未充实，最终可能会达到 5 或 6 层深度）。这与让某些子类仅与其父类有直接关联而不是继承相反。
我读过，深层继承层次结构不是一个好主意，如果子类只是为了拥有父类的数据而继承，那么您应该简单地将父类作为数据包含在子类中，但我很难是时候思考为什么了。如果我决定将继承层次结构设置为 7 深或类似的东西，我们会发生什么糟糕的事情？显然，性能会受到很小的影响，并且更改层次结构顶部的内容将会在整个应用程序中产生巨大的涟漪，但除此之外，我没有看到任何问题。除此之外，我不太关心性能上的微小差异。
（额外问题：是否有一个现成的软件包可以处理此类内容？我们已经处理了大部分低级物理模拟，但我们必须编写排序程序。我只是怀疑我所阐述的内容与我之前的 10,000 名模拟开发人员所做的非常相似。）
如果子类继承只是为了拥有父类的数据
这是一个坏主意。有一种理解是，您将基类定义为一组（具体）类将遵守的最通用的契约。这通常意味着您的合同大约是behavior而不是实施。
如果我决定将继承层次结构设置为 7 深或类似的东西，我们会发生什么糟糕的事情？
这里的主要问题很平常：
- 脆弱的基类（对基类的更改对于派生类来说是一场噩梦）
- 增加耦合（基类过多导致耦合紧密）
- 封装性减弱
- 测试问题（由于此处和那里存在多个链式调用，因此不能仅测试叶级覆盖方法以始终正确地重现最终用户行为）
- 维护（来自强耦合）
（你们很多人想仔细阅读这篇论文为什么艾达不受欢迎 http://www.adapower.com/adapower1/articles/popularity.html，特别是第 6 项第 6 段。）
有没有现成的包可以处理这类事情？
我不确定您在寻找什么，但如果您正在寻找自动层次结构简化器，那么我不知道有什么。此外，如果存在这样的包，它将高度依赖于您选择的语言，而您没有提到其中之一。
请注意，大多数时候此类问题可以通过查看聚合、特征或依赖注入等替代方案来解决。这些是设计时问题，通常（IMO）最好在白板上解决，而不是使用编译器和数百万个 LOC。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
