oop - 继承优于组合

Question

使用组合而不是继承的好处是众所周知的。

在哪些情况下更可取相反？

实际上，我可以看到强制使用基本构造函数的优势，但我想知道其他人对其他案例/领域的看法。

Answer 1

我相信“优先组合优于继承”的著名建议是在 GoF 设计模式一书中提出的。

它说(第 20 页):

Favor object composition over class inheritance.

Ideally, you shouldn't have to create new components to achieve reuse. You should be able to get all the functionality you need just by assembling existing components through object composition. But this is rarely the case, because the set of available components is never quite rich enough in practice. Reuse by inheritance makes it easier to make new components that can be composed with old ones. Inheritance and object composition thus work together.

Nevertheless, our experience is that designers overuse inheritance as a reuse technique, and designs are often made more reusable (and simpler) by depending more on object composition. You'll see object composition applied again and again in the design patterns.

请注意，此语句指的是类继承，必须与接口(interface)继承区分开来，这很好。

活力

两者都是实现可重用性的方法，但组合相对于继承的优势在于动态性。由于组合可以在运行时动态更改，这代表了一个很大的优势，而继承是在编译时静态定义的。

封装

此外，组合基于使用组合对象的公共(public)接口(interface)，因此对象尊重彼此的公共(public)接口(interface)，因此这促进了封装。另一方面，继承破坏了封装，因为子组件通常使用父组件的 protected 接口(interface)。众所周知的问题是父类的变化会破坏子类，即著名的基类问题。同样在继承父类中定义了子类的物理表示，因此子类依赖于父类来进化。

凝聚力

作文的另一个优点是它使类(class)专注于一项任务，这也促进了凝聚力。

负债

显然，组合的一个问题是您将拥有更多的对象和更少的类。这使得可视化您的设计以及它如何实现其目标变得更加困难。在调试代码时，除非您知道对象当前正在使用给定组合的确切实例，否则很难知道发生了什么。所以在我看来，构图让设计更难理解。

由于组合的优点是多重的，这就是为什么建议优先使用它而不是继承，但这并不意味着继承总是不好的。如果正确使用继承，您可以取得很大的成就。

有趣的引用资料

我建议研究 GoF Design Patterns查看两种类型的可重用性的良好示例，例如 Strategy Pattern使用合成与 Template Method使用继承。

大多数模式都大量使用接口(interface)继承和对象组合来实现其目标，只有少数模式使用类继承作为可重用机制。

如果您想深入了解本书 Holub on Patterns ，在第 2 章有一个部分叫做为什么 extends是邪恶的，它深入研究了类继承的责任。

书中提到了三个具体方面

• Losing Flexibility: The first problem is that explicit use of a concrete-class name locks you into a specific implementation, making down-the-line changes unnecessarily difficult.
• Coupling: A more important problem with implementation inheritance is coupling, the undesirable reliance of one part of a program on another part. Global variables are the classic example of why strong coupling is bad. If you change the type of a global variable, for example, all the code that uses that variable—that is coupled to the variable—can be affected, so all this code must be examined, modified, and retested. Moreover, all the methods that use the variable are coupled to each other through the variable. That is, one method may incorrectly affect the behavior of another method simply by changing the variable’s value at an awkward time. This problem is particularly hideous in multithreaded programs.
• Fragile-Base-Class Problem: In an implementation-inheritance system (one that uses extends), the derived classes are tightly coupled to the base classes, and this close connection is undesirable. Designers have applied the moniker “the fragile-base-class problem” to describe this behavior. Base classes are considered “fragile” because you can modify a base class in a seemingly safe way, but this new behavior, when inherited by the derived classes, may cause the derived classes to malfunction.