c# - 长继承层次

Question

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

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

ETC...

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

我怎样才能改变我的架构？什么设计模式适用于我的案例？不好的是我可以更改继承层次结构的位置MyAbstractPageableTable 和位置。MyAbstractScrollableTable因为我的目标是单一职责，所以这两个类没有混为一谈。我还想为用户提供不同的接口（API）

score 1 · Accepted Answer

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

在你的例子中，我猜你可以做一个表格实现并给它一个策略对象来处理例如分页或表格应该支持的任何其他显示策略。

根据 Joshua Bloch 的“Effective Java”，通常使用组合优于继承。我不认为更大的继承深度是坏事，只要它们可以理解，我猜有 11 个级别。

score 0 · Accepted Answer

作品。您会得到两个较小的继承层次结构：

class MyAbstractObject
    class MyAbstractUIObject : MyAbstractObject
        class MyAbstractTable : MyAbstractUIObject

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

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

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

但是，有没有可以更改的课程？例如，ScrollableTable 派生自 PageableTable 是否真的有意义，或者您可以创建接口 IScrollableTable 和 IPageableTable？

c# - 长继承层次

4 回答 4

Related

Reference