这里没有找到满意的答案，所以我写了一个新的。

为了理解为什么“更喜欢组合而不是继承”，我们需要首先找回这个缩短的习惯用法中省略的假设。

继承有两个好处：子类型化和子类化

子类型化意味着符合类型（接口）签名，即一组API，并且可以覆盖部分签名以实现子类型化多态性。子类化意味着方法实现的隐式重用。

这两个好处带来了两个不同的继承目的：面向子类型和面向代码重用。

如果代码重用是唯一的目的，那么子类化可能会给一个比他所需要的更多的东西，即父类的一些公共方法对于子类来说没有多大意义。在这种情况下，不赞成组合而不是继承，而是要求组合。这也是“is-a”与“has-a”概念的由来。

因此，只有当有了子类型，即以后以多态的方式使用新类时，我们才会面临选择继承或组合的问题。这是在所讨论的缩短成语中被省略的假设。

To子类型要符合类型签名，这意味着组合必须始终公开不少于该类型的API数量。现在开始进行权衡：

继承提供了直接的代码重用（如果不被重写），而组合必须对每个API重新编码，即使这只是一个简单的委托工作。继承通过内部多态站点this提供了直接的开放递归，即在另一个成员函数中调用重写方法（甚至类型），无论是公共的还是私有的（尽管不鼓励）。开放递归可以通过组合来模拟，但它需要额外的努力，并且可能并不总是可行的（？）。对重复问题的回答也有类似之处。继承公开受保护的成员。这打破了父类的封装，如果被子类使用，则会引入子类和父类之间的另一个依赖关系。组合具有控制反转的特性，其依赖性可以动态注入，如装饰器模式和代理模式所示。组合具有面向组合器编程的优点，即以类似于组合模式的方式工作。编程到接口后立即进行组合。组合具有易于多重继承的优点。

考虑到上述权衡，我们因此更喜欢组合而不是继承。然而，对于紧密相关的类，即当隐式代码重用真正带来好处，或者需要开放递归的魔力时，继承应该是选择。

我看没有人提到钻石问题，这可能是继承带来的。

总之，如果类B和C继承了a，并且都重写了方法X，而第四个类D继承了B和C，并且没有重写X，那么应该使用X D的哪个实现？

维基百科对这个问题中讨论的主题提供了一个很好的概述。

我听过的一条经验法则是，当它是一种“is-A”关系时，应该使用继承；当它是“has-A”关系的时候，应该使用组合。尽管如此，我觉得你应该始终倾向于构图，因为它消除了很多复杂性。

除了是/有一个考虑因素之外，还必须考虑对象必须经历的继承的“深度”。任何超过五或六级继承深度的内容都可能会导致意外的强制转换和装箱/拆箱问题，在这种情况下，编写对象可能是明智的。

简单地说，实现就像你（类）应该遵循的规则

但是扩展就像对很多类使用公共代码，也许只是其中一个需要重写。

继承是非常强大的，但你不能强迫它（参见：圆-椭圆问题）。如果你真的不能完全确定一个真正的“is-a”子类型关系，那么最好是组合。