长继承层次结构

Question

我有很长的类继承层次结构。例如：

-MyAbstractObject
--MyAbstractUiObject
---MyAbstractTable
-----MyAbstractPageableTable
-------MyAbstractScrollableTable
---------MyAbstractStateblaTable

等...

我在Code complete读到，理想的继承深度为3.有时候允许继承深度为7-9。但我有继承深11！

我如何改变我的架构？什么样的设计模式适用于我的案例？不好的是，我可以在继承层次结构中更改MyAbstractPageableTable和MyAbstractScrollableTable的位置。这2个课程没有混合成一个，因为我的目标是单一责任。另外，我想为用户提供不同的接口（API）

Answer 1

通常最好使用策略模式而不是为每个用例创建一个子类。但很难提出任何有用的建议，因为这取决于具体情况。

在您的示例中，我猜您可以执行表实现并为其提供一个策略对象，该对象可以处理例如Pagenation或表应支持的任何其他显示策略。

根据约书亚布洛赫的“有效Java”，使用构图而不是继承更好。我不认为更大的遗产深度是坏的，只要它们可以理解，有11个等级，我猜不会是这种情况。

Answer 2

组合物。您将获得两个较小的继承层次结构：

class MyAbstractObject
    class MyAbstractUIObject : MyAbstractObject
        class MyAbstractTable : MyAbstractUIObject

interface IMyAbstractTableBehaviour { void Perform(); }
    class MyAbstractTablePageableBehaviour : IMyAbstractTableBehaviour
    class MyAbstractTableScrollableBehaviour : IMyAbstractTableBehaviour
    class MyAbstractTableStateableBehaviour : IMyAbstractTableBehaviour

您可以使用这三种行为的任意组合来实例化MyAbstractTable的子类，并且实现其他行为是微不足道的。

Answer 3

我不知道代码是完整的，但理想的继承可能只是正确方向的信号（指导），它不适用于所有情况（也许是你的案例就是其中之一）。 UI控件的继承层次结构通常具有这种现象，例如WPF中的控件（Windows Presentation Foundation）。因此，如果您正在构建UI框架，则可能会遇到此问题。 依赖（您的具体情况）取决于，但总体继承增加了代码中的耦合，并且@Casey表示如果可能，您应该支持Composition。

Answer 4

在问题中没有更多细节，很难给出具体的答案。

使用UI框架（您的类似乎是其中的一部分），您确实倾向于拥有比普通继承层次更深的层次结构。顶部的类倾向于处理布局等，因此在添加渲染和自定义行为类之前，您需要深入了解几个。

但是，有没有可以改变的课程？例如，ScrollableTable从PageableTable派生是否真的有意义，还是可以创建接口IScrollableTable和IPageableTable？