理解这一点的一个简单方法是，当您需要类的对象与其父类具有相同的接口时，应该使用继承，这样它就可以被视为父类的对象（上广播）。此外，派生类对象上的函数调用在代码中的任何地方都保持不变，但要调用的特定方法将在运行时确定（即，低级实现不同，高级接口保持不变）。

当您不需要新类具有相同的接口时，即您希望隐藏该类的用户不需要知道的类实现的某些方面时，应使用组合。因此，组合更多的是支持封装（即隐藏实现），而继承意味着支持抽象（即提供某种东西的简化表示，在这种情况下，相同的接口用于具有不同内部结构的一系列类型）。

假设飞机只有两个部分：发动机和机翼。然后有两种设计飞机等级的方法。

Class Aircraft extends Engine{
  var wings;
}

现在你的飞机可以从固定机翼开始并在飞行中将其改为旋转翼。它本质上是有翅膀的发动机。但如果我想改变呢发动机也在飞行？

基类Engine公开一个赋值函数以更改其财产，或我将飞机重新设计为：

Class Aircraft {
  var wings;
  var engine;
}

现在，我也可以随时更换发动机。

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

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

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

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

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

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

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

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

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

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

正如许多人所说的，我首先要检查是否存在“是”的关系。如果存在，我通常检查以下内容：

是否可以实例化基类。也就是说，基类是否可以是非抽象的。如果可以是非抽象的，我通常更喜欢写作

例如1。会计是员工。但我不会使用继承，因为Employee对象可以实例化。

例如2。书籍是SellingItem。SellingItem无法实例化-它是抽象概念。因此，我将使用遗传痤疮。SellingItem是一个抽象基类（或C#中的接口）

你觉得这种方法怎么样？

此外，我支持为什么要使用继承？

使用继承的主要原因不是作为组合的一种形式，而是为了让您可以获得多态行为。如果不需要多态性，那么可能不应该使用继承。

@马修。在https://softwareengineering.stackexchange.com/questions/12439/code-smell-inheritance-abuse/12448#comment303759_12448

继承的问题在于它可以用于两个正交的目的：接口（用于多态性）实现（用于代码重用）

参考

哪个班级设计更好？继承与聚合

继承是非常诱人的，尤其是来自程序领域的继承，它通常看起来很优雅。我的意思是，我需要做的就是将这一点功能添加到其他类中，对吗？嗯，问题之一是继承可能是最糟糕的耦合形式

基类通过以受保护成员的形式向子类公开实现细节来打破封装。这会使您的系统变得僵化和脆弱。然而，更悲惨的缺陷是新的子类带来了继承链的所有包袱和观点。

《继承是邪恶的：DataAnnotationsModelBinder的史诗般的失败》一文在C#中讲述了一个这样的例子。它显示了继承在何时应该使用组合以及如何重构组合。

就我个人而言，我学会了总是喜欢组合而不是继承。没有可以用继承解决的编程问题，而不能用组合解决；尽管在某些情况下，您可能必须使用接口（Java）或协议（Obj-C）。因为C++不知道任何这类东西，所以您必须使用抽象基类，这意味着您无法完全摆脱C++中的继承。

组合通常更符合逻辑，它提供了更好的抽象、更好的封装、更好的代码重用（尤其是在非常大的项目中），并且不太可能因为您在代码中的任何地方进行了孤立的更改而在远处破坏任何东西。这也使得维护“单一责任原则”变得更容易，该原则通常被概括为“一个类的改变不应该有一个以上的原因”，这意味着每个类都是为了一个特定的目的而存在的，它只应该有与其目的直接相关的方法。此外，拥有一个非常浅的继承树，即使您的项目开始变得非常大，也可以更容易地保持概述。许多人认为遗产很好地代表了我们的现实世界，但事实并非如此。现实世界使用的合成比继承多得多。几乎每一个你能拿在手中的现实世界物体都是由其他更小的现实世界对象组成的。

不过，组合也有缺点。如果您完全跳过继承，只关注组合，您会注意到，如果您使用了继承，通常需要编写一些额外的代码行。你有时也会被迫重复自己，这违反了干原则（干=不要重复自己）。此外，组合通常需要委托，一个方法只是调用另一个对象的另一个方法，而没有其他代码围绕此调用。这种“双重方法调用”（可能很容易扩展到三重或四重方法调用，甚至更远）的性能要比继承差得多，因为继承只是继承父级的方法。调用继承的方法可能与调用非继承的方法一样快，也可能稍慢，但通常仍比两个连续的方法调用快。

您可能已经注意到，大多数OO语言不允许多重继承。虽然在一些情况下，多重继承确实可以为您带来一些东西，但这些都是例外，而不是规则。每当你遇到一个你认为“多重继承将是解决这个问题的一个非常酷的特性”的情况时，你通常都应该重新考虑继承，因为即使它可能需要一些额外的代码行，基于组合的解决方案通常会变得更加优雅、灵活和经得起未来考验。

继承确实是一个很酷的功能，但我担心它在过去几年中被过度使用了。人们将遗产视为一把能钉住一切的锤子，不管它实际上是一颗钉子、一颗螺丝钉，还是一个完全不同的东西。