简而言之，我同意“比起继承，我更喜欢成分”，但对我来说，这听起来常常像“比起可口可乐，我更爱土豆”。有继承的地方，也有合成的地方。你需要了解差异，然后这个问题就会消失。这对我来说真正的意义是“如果你要使用继承——再想想，你很可能需要复合”。

当你想吃的时候，你应该更喜欢土豆而不是可口可乐，当你想喝的时候，应该更喜欢可口可乐而不是土豆。

创建子类不仅仅意味着调用超类方法的便捷方式。当子类在结构上和功能上都是一个超级类时，您应该使用继承，因为它可以用作超级类，并且您将使用它。如果不是这样的话，那不是继承，而是其他东西。合成是指你的对象由另一个组成，或者与它们有某种关系。

所以对我来说，如果有人不知道自己是否需要继承或组成，真正的问题是他不知道自己是想喝酒还是想吃饭。多想想你的问题领域，更好地理解它。

要从新程序员的不同角度解决这个问题：

当我们学习面向对象的编程时，继承经常很早就被教授，因此它被视为一个常见问题的简单解决方案。

我有三个类都需要一些通用功能。所以如果我编写一个基类并让它们全部继承，然后它们将所有这些都有这个功能，我只需要维护一次位置

这听起来很好，但实际上它几乎从未奏效，原因如下：

我们发现，我们希望我们的类具有其他一些功能。如果我们向类添加功能的方式是通过继承，那么我们必须决定——我们是否将其添加到现有基类中，即使不是每个从其继承的类都需要该功能？我们是否创建另一个基类？但是，已经从其他基类继承的类呢？我们发现，对于从基类继承的一个类，我们希望基类的行为稍有不同。所以现在我们回过头来修改我们的基类，可能会添加一些虚拟方法，或者更糟的是，一些代码会说，“如果我是继承的类型A，那么就这样做，但如果我是传承的类型B，那么就那样做。”这是很糟糕的，原因很多。一个是，每次我们改变基类时，我们都在有效地改变每个继承的类。所以我们真的在改变A、B、C和D类，因为我们需要在A类中有一个稍微不同的行为。尽管我们认为我们很小心，但我们可能会因为与这些类无关的原因而破坏其中一个类。我们可能知道为什么我们决定让所有这些类彼此继承，但这对其他必须维护我们代码的人来说可能没有意义。我们可能会迫使他们做出一个艰难的选择——我是做一些非常丑陋和混乱的事情来做出我需要的改变（见前面的要点），还是只是重写一堆内容。

最后，我们把代码绑在一些困难的地方，除了说：“酷，我了解了继承，现在我使用了它。”这并不意味着居高临下，因为我们都这样做了。但我们都这么做了，因为没有人告诉我们不要这样做。

当有人向我解释“喜欢组合而不是继承”时，我回想了一下每次尝试使用继承在类之间共享功能时，我都意识到大多数时候它并没有真正发挥作用。

解药是单一责任原则。将其视为约束。我的班级必须做一件事。我必须能够给我的班级起一个名字，以某种方式描述它所做的一件事。（凡事都有例外，但当我们学习时，绝对规则有时会更好。）因此，我无法编写名为ObjectBaseThatContainsVariousFunctionsNeedByDifferentClasses的基类。我所需要的任何不同的功能都必须在它自己的类中，然后需要该功能的其他类可以依赖于该类，而不是从该类继承。

在过于简化的风险下，这就是组合——组合多个类一起工作。一旦我们养成了这个习惯，我们就会发现它比使用继承更灵活、更可维护、更可测试。

如果你明白其中的区别，那么解释起来就更容易了。

程序代码

这方面的一个例子是不使用类的PHP（尤其是在PHP5之前）。所有逻辑都编码在一组函数中。您可以包含包含助手函数等的其他文件，并通过在函数中传递数据来执行业务逻辑。随着应用程序的增长，这可能很难管理。PHP5试图通过提供更面向对象的设计来解决这一问题。

遗产

这鼓励使用类。继承是OO设计的三大原则之一（继承、多态性、封装）。

class Person {
   String Title;
   String Name;
   Int Age
}

class Employee : Person {
   Int Salary;
   String Title;
}

这是工作中的继承。员工“是”个人或继承自个人。所有继承关系都是“is-a”关系。Employee还隐藏Person的Title属性，意思是Employee.Title将返回Employees的Title，而不是Person。

作文

组合比继承更受欢迎。简单地说，你应该：

class Person {
   String Title;
   String Name;
   Int Age;

   public Person(String title, String name, String age) {
      this.Title = title;
      this.Name = name;
      this.Age = age;
   }

}

class Employee {
   Int Salary;
   private Person person;

   public Employee(Person p, Int salary) {
       this.person = p;
       this.Salary = salary;
   }
}

Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);

组成通常是“有”或“使用”关系。这里Employee类有一个Person。它不从Person继承，而是将Person对象传递给它，这就是它“有”Person的原因。

继承上的组合

现在，假设您要创建一个管理器类型，这样您就可以：

class Manager : Person, Employee {
   ...
}

但是，如果Person和Employee都声明了Title，那么这个示例会很好用？经理头衔应该返回“运营经理”还是“先生”？在合成中，这种模糊性得到了更好的处理：

Class Manager {
   public string Title;
   public Manager(Person p, Employee e)
   {
      this.Title = e.Title;
   }
}

Manager对象由Employee和Person组成。标题行为取自雇员。这种显式组合消除了其他问题中的歧义，您将遇到更少的错误。

这两种方式可以很好地生活在一起，并相互支持。

组合只是将其模块化：您创建类似于父类的接口，创建新对象并将调用委托给它。如果这些对象不需要彼此了解，那么组合是非常安全且易于使用的。这里有很多可能性。

然而，如果父类出于某种原因需要访问“子类”为没有经验的程序员提供的函数，那么它可能看起来是一个使用继承的好地方。父类可以只调用它自己的抽象“foo（）”，该抽象被子类覆盖，然后它可以将值赋给抽象基。

这看起来是一个不错的想法，但在许多情况下，只给类一个实现foo（）的对象（或者甚至手动设置foo）提供的值）要好于从需要指定foo函数的基类继承新类。

Why?

因为继承是传递信息的一种糟糕方式。

组合在这里有一个真正的优势：关系可以颠倒：“父类”或“抽象工作者”可以聚合实现特定接口的任何特定“子”对象+任何子对象都可以设置在接受其类型的任何其他类型的父类中。而且可以有任意数量的对象，例如MergeSort或QuickSort可以对实现抽象比较接口的任何对象列表进行排序。或者换一种说法：实现“foo（）”的任何一组对象和可以使用具有“foo）”的对象的其他一组对象都可以一起玩。

我可以想到使用继承的三个真正原因：

您有许多具有相同接口的类，您希望节省编写它们的时间必须为每个对象使用相同的基类您需要修改私有变量，在任何情况下都不能是公共的

如果这些都是真的，那么可能需要使用继承。

使用原因1没有什么不好的，在对象上有一个坚实的界面是非常好的。这可以使用组合或继承来完成，没有问题——如果这个接口简单且不改变。通常，继承在这里非常有效。

如果原因是第二，那就有点棘手了。你真的只需要使用相同的基类吗？一般来说，仅仅使用相同的基类是不够的，但这可能是框架的一个要求，这是一个无法避免的设计考虑。

然而，如果您想使用私有变量，即案例3，那么您可能会遇到麻烦。如果您认为全局变量不安全，那么应该考虑使用继承来访问私有变量也不安全。请注意，全局变量并不是那么糟糕——数据库本质上是一组全局变量。但如果你能处理，那就很好了。

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

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

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

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

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

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

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

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

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

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

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

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

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