深层类继承层次结构--不好的主意？
希望一位特级大师能给我们一些启示。非常高的概述是，我不是编程的初学者，但仍然是OOP的新手。这组消息类是我们正在编写的一个大型模拟应用程序的核心，我不想愚蠢地这么做--这个接口将应用程序从定序器到执行器一分为二，反之亦然。
我的问题是，拥有这么深的继承层次结构是不是一个坏主意(图像还没有充实，最终可能会深入5到6层)。这与一些子类只有一个指向父类的关联，而不是继承相反。
我读到过，深度继承层次结构不是一个好主意，如果子类只是为了拥有父类的数据而继承，那么您应该简单地将父类作为数据包含在子类中，但我很难理解为什么。如果我决定创建一个7层的继承层次结构或者类似的东西，会发生什么不好的事情呢？显然有一个小的性能冲击，在层次结构的顶部改变东西将在整个应用程序中产生巨大的涟漪，但除此之外，我看不到任何问题。另外，我并不关心性能上的细微差别。
(奖励问题:有没有现成的包来处理这类事情？我们已经处理了大多数低级物理模拟，但我们将不得不编写序列程序。我只是怀疑我列出的内容与我之前的大约10,000名模拟开发人员非常相似。)
(奖励问题#2:有没有同时精通模拟系统和OOP编程的大师，不讨厌住在洛杉矶？我们正在招聘。)
回答 3
Stack Overflow用户
发布于 2012-06-16 03:37:16
表示，如果子类只是继承父类的数据
这不是个好主意。有这样一种理解，即您将基类定义为一组(具体)类将要遵守的最通用的契约。这通常意味着你的契约是关于行为的，而不是实现的。
如果我决定创建一个7层的继承层次结构，会发生什么不好的事情呢？
这里的主要问题是平凡的：
derived)
- Increased
- 脆弱的基类(对基类的更改是derived)
- Increased耦合的噩梦)(太多的基类带来了严格的coupling)
- Encapsulation weakens
- Testing问题(叶级覆盖的方法不能只是测试就能正确地再现最终用户行为，因为这里有多个链式调用和there)
- Maintenance (来自强耦合)
(您可以仔细阅读这篇关于Why Ada isn't popular的论文，特别是第6项第6段。)
有没有现成的包来处理这类事情？
我不确定你在寻找什么，但如果你正在寻找一个自动化的层次结构简化器，那么我不知道任何一个。此外，如果存在这样的包，它将高度依赖于您选择的语言，而您还没有提到一个。
请注意，大多数情况下，这些问题可以通过查看聚合或特征或依赖注入等替代方案来解决。这些都是设计时的问题，通常(IMO)最好在白板上解决，而不是使用编译器和数百万的LOC。
Stack Overflow用户
发布于 2015-04-21 12:20:46
看到这个问题已经很晚了，但我已经对这个问题有了很多想法，并且已经被深层的继承层次结构所困扰。它们不好的一个原因是，当您专门化许多子类时，不可避免地会出现分类错误。然而，一旦你有了类结构，它将很难改变，因为这样做会破坏客户端代码。
我写了关于这个here的博客。
Stack Overflow用户
发布于 2021-10-04 09:19:52
老问题，但在软件开发中的活跃问题，并想添加一个意见，可能会有所帮助。
当您使用DI接触基类时，无法估计维护开销。这是最近影响我们3级深度继承结构的一个主要缺点。此外，如果你的基础是一个模板，如果你有太多的子代，例如在3个级别中只有一个派生的父代，那么就会违反SOL(I)(D)。
一般来说，为了访问数据，我会选择一个适当的设计模式，或者传递数据指针，如果它不违反SOLID的话。根据你是读还是写，我也会避免使用getter和setter来避免Quasi-Classes。默认的子级被“保护”的情况很少见，我认为这种情况下的结构是一个设计缺陷的候选者。
https://stackoverflow.com/questions/11056943
复制相似问题
腾讯云开发者
