将遏制视为一种关系。汽车“有”发动机，人“有”名字等等。

把继承看作是一种关系。汽车“是”车辆，人“是”哺乳动物等。

我不认为这种做法值得赞扬。我直接从史蒂夫·麦康奈尔（Steve McConnell）的《代码大全》第二版第6.3节中得到了答案。

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

在Java或C#中，对象一旦实例化就不能更改其类型。

因此，如果您的对象需要显示为不同的对象或根据对象的状态或条件表现出不同的行为，那么请使用组合：参考状态和策略设计模式。

如果对象需要具有相同的类型，则使用继承或实现接口。

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

另一个非常实用的原因是，倾向于组合而不是继承，这与域模型以及将其映射到关系数据库有关。将继承映射到SQL模型真的很难（你最终会遇到各种棘手的变通方法，比如创建不经常使用的列、使用视图等）。一些ORML试图处理这个问题，但它总是很快变得复杂。通过两个表之间的外键关系可以很容易地对组合进行建模，但继承要困难得多。

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

更喜欢组合而不是继承，因为它更具延展性/更易于稍后修改，但不要使用组合始终方法。通过组合，使用依赖注入/设置器可以很容易地动态改变行为。继承更为严格，因为大多数语言不允许从多个类型派生。因此，一旦你从A型衍生出，鹅或多或少都是熟的。

我的上述酸性测试是：

TypeB是否希望公开TypeA的完整接口（所有公共方法都不少于），以便在需要TypeA的地方使用TypeB？表示继承。例如，赛斯纳双翼飞机将暴露出飞机的完整界面，如果不是更多的话。因此，它适合于从飞机衍生。TypeB是否只想要TypeA暴露的部分行为？表示需要合成。例如，鸟可能只需要飞机的飞行行为。在这种情况下，将其作为接口/类/两者提取出来并使其成为两个类的成员是有意义的。

更新：刚刚回到我的答案，现在看来，如果没有具体提到芭芭拉·里斯科夫的里斯科夫替代原则作为“我应该继承这种类型吗？”的测试，它似乎是不完整的

当您想要“复制”/公开基类的API时，可以使用继承。当您只想“复制”功能时，请使用委派。

其中的一个例子是：您想要从列表中创建堆栈。堆栈只有pop、push和peek。考虑到堆栈中不需要push_back、push_front、removeAt等功能，您不应该使用继承。

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

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

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

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

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

程序代码

这方面的一个例子是不使用类的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组成。标题行为取自雇员。这种显式组合消除了其他问题中的歧义，您将遇到更少的错误。

继承在子类和超级类之间建立了牢固的关系；子类必须了解超级类的实现细节。创建超级类要困难得多，因为你必须考虑如何扩展它。您必须仔细记录类不变量，并说明其他可重写方法在内部使用的方法。

如果层次结构真的代表了一种is-a-关系，那么继承有时是有用的。它与开放-封闭原则有关，该原则规定类应该封闭以进行修改，但开放以进行扩展。这样你就可以拥有多态性；需要一个处理超类型及其方法的泛型方法，但通过动态调度调用子类方法。这是灵活的，有助于创建间接，这在软件中是必不可少的（对实现细节了解较少）。

然而，继承很容易被过度使用，并且会产生额外的复杂性，导致类之间存在硬依赖关系。此外，由于层和方法调用的动态选择，很难理解程序执行过程中发生的事情。

我建议使用作曲作为默认设置。它更加模块化，并提供了后期绑定的好处（您可以动态更改组件）。另外，单独测试这些东西更容易。如果您需要使用类中的方法，则不必强制使用某种形式（Liskov替换原则）。

继承带来了所有不可否认的好处，下面是它的一些缺点。

继承的缺点：

您不能在运行时更改从超级类继承的实现（显然是因为继承是在编译时定义的）。继承将子类暴露给其父类实现的细节，这就是为什么人们常说继承破坏了封装（从某种意义上讲，您真正需要关注的是接口而不是实现，所以通过子类重用并不总是首选的）。继承提供的紧密耦合使得子类的实现与超级类的实现紧密结合，父类实现中的任何更改都将迫使子类进行更改。子类的过度重用会使继承堆栈变得很深，也很混乱。

另一方面，通过对象获取对其他对象的引用，在运行时定义对象组合。在这种情况下，这些对象将永远无法访问彼此的受保护数据（没有封装中断），并将被迫尊重彼此的接口。在这种情况下，实现依赖性也会比继承的情况下少得多。

你想强迫自己（或其他程序员）坚持什么，什么时候你想让自己（或另一个程序员）有更多的自由。有人认为，当你想强迫某人以某种方式处理/解决某个特定问题时，继承是有帮助的，这样他们就不会走错方向。

Is-a和Has-a是一个有用的经验法则。

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

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

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

你需要看看Bob叔叔的SOLID类设计原则中的Liskov替换原则。：）

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

Class Aircraft extends Engine{
  var wings;
}

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

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

Class Aircraft {
  var wings;
  var engine;
}

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

在可以枚举不变量的情况下，子类型更合适，功能更强大，否则使用函数组合实现可扩展性。

我同意@帕维尔的说法，他说，有地方可以组成，也有地方可以继承。

我认为如果你的答案是肯定的，那么应该使用继承。

您的类是从多态性中受益的结构的一部分吗？例如，如果您有一个Shape类，它声明了一个名为draw（）的方法，那么我们显然需要Circle和Square类作为Shape的子类，这样它们的客户端类将依赖于Shape而不是特定的子类。您的类是否需要重用其他类中定义的任何高级交互？如果没有继承，模板方法设计模式将不可能实现。我相信所有可扩展框架都使用这种模式。

然而，如果您的意图纯粹是代码重用，那么组合很可能是更好的设计选择。

我的经验法则是：在使用继承之前，考虑组合是否更有意义。

原因：子类化通常意味着更复杂和更紧密，即更难在不出错的情况下进行更改、维护和扩展。

Sun的Tim Boudreau给出了一个更完整、更具体的答案：

在我看来，使用继承的常见问题是：无辜的行为可能会产生意想不到的结果——这方面的经典例子是调用超类中的可重写方法构造函数，在子类实例字段初始化。在一个完美的世界里，没有人会这样做。这是不是一个完美的世界。它给子类提供了不正当的诱惑，让它们对方法调用的顺序等做出假设——这种假设往往不会如果超类可以随着时间的推移而发展，那么它是稳定的。另请参见我的烤面包机和咖啡壶类比。类变得更重了——你不一定知道你的超类在其构造函数中做了什么工作，或者它需要多少内存使用。因此，构建一些无辜的轻量级对象可以比你想象的要贵得多，如果超类进化它鼓励子类的爆炸。类加载需要时间，更多的类需要内存。在你与NetBeans规模的应用程序打交道，但在那里，我们有了真正的例如，由于第一次显示菜单触发了大量的类加载。我们通过移动到更多的声明性语法和其他技术，但这需要花费时间修复。这使得以后改变事情变得更加困难——如果你公开了一个类，那么交换超类会破坏子类-这是一个选择，一旦你公开了代码，你就结婚了所以如果你不改变你的真实功能超类，如果你使用，而不是扩展你需要的东西。例如，子类化JPanel-这通常是错误的；如果子类是在公共场所，你永远不会有机会重新审视这个决定。如果它作为JComponent getThePanel（）访问，您仍然可以这样做（提示：将组件的模型作为API公开）。对象层次结构不可缩放（或使其稍后缩放比提前规划要困难得多）-这是经典的“太多层”问题我将在下面讨论AskTheOracle模式如何解决它（尽管它可能冒犯OOP纯粹主义者）。...如果你允许继承遗产，我会怎么做带着一粒盐是：永远不显示字段，常量除外方法应为抽象方法或最终方法不从超类构造函数调用任何方法...所有这些都不适用于小型项目，而适用于大型项目私人课程比公共课程

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

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

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

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

你觉得这种方法怎么样？

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

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

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

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

参考

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

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

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

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

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

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

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

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

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

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

Why?

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

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

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

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

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

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

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

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

继承是一种非常强大的代码重用机制。但需要正确使用。如果子类也是父类的子类型，我会说继承是正确使用的。如上所述，利斯科夫替代原则是这里的关键点。

子类与子类型不同。您可以创建不是子类型的子类（此时应该使用组合）。为了理解什么是子类型，让我们开始解释什么是类型。

当我们说数字5是整数类型时，我们说明5属于一组可能的值（例如，请参阅Java原语类型的可能值）。我们还声明，我可以对值执行一组有效的方法，如加法和减法。最后，我们要说明的是，有一组财产总是可以满足的，例如，如果我将值3和5相加，结果会得到8。

举另一个例子，考虑抽象数据类型，整数集合和整数列表，它们可以保存的值仅限于整数。它们都支持一组方法，如add（newValue）和size（）。而且它们都有不同的财产（类不变量），Sets不允许重复，而List允许重复（当然还有它们都满足的其他财产）。

子类型也是一种类型，它与另一种类型（称为父类型（或父类型））有关系。子类型必须满足父类型的功能（值、方法和财产）。这种关系意味着在任何期望超类型的上下文中，它都可以被子类型替代，而不会影响执行的行为。让我们去看一些代码来举例说明我在说什么。假设我写了一个整数列表（用某种伪语言）：

class List {
  data = new Array();

  Integer size() {
    return data.length;
  }

  add(Integer anInteger) {
    data[data.length] = anInteger;
  }
}

然后，我将整数集合写成整数列表的子类：

class Set, inheriting from: List {
  add(Integer anInteger) {
     if (data.notContains(anInteger)) {
       super.add(anInteger);
     }
  }
}

我们的整数集合类是整数列表的子类，但不是子类型，因为它不满足列表类的所有特性。满足了方法的值和签名，但不满足财产。add（Integer）方法的行为已经明显改变，没有保留父类型的财产。从类的客户端的角度思考。他们可能会收到一组整数，其中需要一个整数列表。客户端可能希望添加一个值，并将该值添加到列表中，即使该值已经存在于列表中。但如果价值存在，她就不会有这种行为。她大吃一惊！

这是一个不正确使用继承的典型例子。在这种情况下使用合成。

（片段来自：正确使用继承）。

当你在两个类之间有一个is-a关系（例如狗是狗），你就去继承。

另一方面，当你在两个班级（学生有课程）或（老师学习课程）之间有一种或某种形容词关系时，你选择了作文。

这条规则完全是无稽之谈。为什么？

原因是，在任何情况下，都可以区分是使用组合还是继承。这取决于对一个问题的回答：“是什么？是什么？”或“有什么？”其他的东西“。

你不能“宁愿”把某样东西变成另一样东西或拥有另一样。严格的逻辑规则适用。

也没有“人为的例子”，因为在任何情况下都可以给出这个问题的答案。

如果你不能回答这个问题，还有其他问题。这包括类的责任重叠，这通常是错误使用接口的结果，较少是通过在不同类中重写相同的代码。

为了避免这种情况，我还建议为类使用与它们的职责完全相似的好名称。

合成与继承是一个广泛的主题。对于什么更好，没有真正的答案，因为我认为这一切都取决于系统的设计。

通常，对象之间的关系类型为选择其中一个对象提供了更好的信息。

如果关系类型是“is-A”关系，则继承是更好的方法。否则关系类型为“HAS-A”关系，则组合将更接近。

这完全取决于实体关系。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

你什么时候可以用作文？

你可以一直使用合成。在某些情况下，继承也是可能的，并可能导致更强大和/或更直观的API，但组合始终是一种选择。

什么时候可以使用继承？

人们常说，如果“bar是foo”，那么bar类可以继承foo类。不幸的是，仅此测试并不可靠，请改用以下方法：

bar是foo，AND酒吧可以做foos所能做的一切。

第一个测试确保Foo的所有getter在Bar中都有意义（=共享的财产），而第二个测试确保所有Foo的setter都在Bar（=共享功能）中有意义。

示例：狗/动物

狗是一种动物，狗可以做动物所能做的一切（如呼吸、移动等）。因此，狗类可以继承动物类。

反例：圆/椭圆

圆是椭圆，但圆不能做椭圆所能做的一切。例如，圆不能拉伸，而椭圆可以拉伸。因此，Circle类不能继承Ellipse类。

这被称为圆椭圆问题，这并不是一个真正的问题，但更多的是表明“一个条就是一个foo”本身不是一个可靠的测试。特别是，这个例子强调了派生类应该扩展基类的功能，而不是限制它。否则，基类不能以多态的方式使用。添加测试“bar可以做foos所能做的一切”确保了多态性的使用是可能的，这相当于Liskov替换原则：

使用基类指针或引用的函数必须能够在不知道的情况下使用派生类的对象

什么时候应该使用继承？

即使你可以使用继承，也不意味着你应该这样做：使用组合总是一种选择。继承是一个强大的工具，允许隐式代码重用和动态分派，但它确实有一些缺点，这就是为什么组合经常被首选的原因。继承和组合之间的权衡并不明显，在我看来，在lcn的回答中可以得到最好的解释。

作为经验法则，当多态性使用被认为非常普遍时，我倾向于选择继承而不是组合，在这种情况下，动态分派的功能可以导致更可读和更优雅的API。例如，在GUI框架中有一个多态类Widget，或者在XML库中有一种多态类Node，这样就可以使用一个比纯基于组合的解决方案更易读、更直观的API。

尽管作文是首选，但我想强调继承的优点和作文的缺点。

继承优势：

它建立了逻辑“IS a”关系。如果汽车和卡车是两种类型的车辆（基类），则子类是一个基类。即汽车就是车辆卡车是一种车辆通过继承，您可以定义/修改/扩展功能基类不提供实现，子类必须重写完整方法（抽象）=>您可以实现合约基类提供默认实现，子类可以更改行为=>您可以重新定义合约子类通过调用super.methodName（）作为第一条语句来向基类实现添加扩展=>您可以扩展合约基类定义了算法的结构，子类将覆盖算法的一部分=>您可以在不改变基类骨架的情况下实现Template_method

组成的缺点：

在继承中，子类可以直接调用基类方法，即使它由于IS A关系而没有实现基类方法。如果使用组合，则必须在容器类中添加方法以公开包含的类API

例如，如果汽车包含车辆，并且您必须获得汽车的价格（已在车辆中定义），您的代码将如下

class Vehicle{
     protected double getPrice(){
          // return price
     }
} 

class Car{
     Vehicle vehicle;
     protected double getPrice(){
          return vehicle.getPrice();
     }
} 

如果你想得到自OOP兴起以来人们一直给出的规范的教科书式答案（你可以看到很多人在这些答案中给出了答案），那么应用以下规则：“如果你有一个is-a关系，那么使用继承。如果你有个has-a关系，则使用组合”。

这是传统的建议，如果这让你满意，你可以停止阅读，继续你的快乐之路。对于其他人。。。

is-a/has-a比较存在问题

例如：

正方形是矩形，但如果矩形类具有setWidth（）/setHeight（）方法，那么没有合理的方法可以在不违反Liskov替换原则的情况下使正方形继承自矩形。is-a关系通常可以被改写为听起来像has-a关系。例如，员工是一个人，但一个人也具有“已就业”的就业状态。如果不小心，is-a关系可能会导致讨厌的多重继承层次结构。毕竟，英语中没有一条规则规定一个对象是一件事情。人们很快就把这条“规则”传递出去了，但有没有人试图支持它，或者解释为什么这是一个很好的启发式方法？当然，这很符合OOP应该模拟真实世界的想法，但这本身并不是采用原则的理由。

有关此主题的更多信息，请参阅StackOverflow问题。

要知道何时使用继承与组合，我们首先需要了解每种方法的利弊。

实现继承的问题

其他答案在解释继承问题方面做了很好的工作，所以我在这里尽量不深入太多细节。但是，这里有一个简短的列表：

很难遵循在基类和子类方法之间交织的逻辑。通过调用另一个可重写的方法在类中不小心地实现一个方法将导致您泄漏实现细节并破坏封装，因为最终用户可能会重写您的方法并检测您何时在内部调用它。（请参阅“有效Java”第18项）。脆弱的基础问题，简单地说，如果最终用户的代码在您尝试更改它们时碰巧依赖于实现细节的泄漏，那么它们就会损坏。更糟糕的是，大多数OOP语言默认允许继承——API设计者如果没有主动阻止人们从公共类继承，那么在重构基类时就需要格外谨慎。不幸的是，脆弱的基础问题经常被误解，导致许多人不理解维护任何人都可以继承的类需要什么。致命的死亡钻石

构图的问题

有时可能有点冗长。

就是这样，我是认真的。这仍然是一个真正的问题，有时会与DRY原则产生冲突，但一般来说，这并没有那么糟糕，至少与继承相关的无数陷阱相比。

什么时候应该使用继承？

下次当你为一个项目绘制你的UML图时（如果你这样做的话），并且你在考虑添加一些继承时，请遵循以下建议：不要。

至少目前还没有。

继承是作为实现多态性的工具出售的，但与它捆绑在一起的是这个强大的代码重用系统，坦率地说，大多数代码都不需要。问题是，一旦你公开了你的继承层次结构，你就被锁定在这种特定的代码重用风格中，即使这对于解决你的特定问题来说是过度的。

为了避免这种情况，我的两分钱是永远不要公开公开你的基类。

如果需要多态性，请使用接口。如果你需要允许人们自定义你的类的行为，通过策略模式提供显式的连接点，这是一种更易读的方式来实现这一点，另外，保持这种API的稳定性更容易，因为你完全可以控制他们可以改变和不能改变的行为。如果您试图通过使用继承来遵循开放-封闭原则，以避免向类添加急需的更新，那么就不要这样做。更新类。如果你真的拥有被雇佣来维护的代码，而不是试图在代码中添加一些东西，那么你的代码库就会更干净。如果你害怕引入bug，那么就对现有代码进行测试。如果需要重用代码，首先尝试使用组合或帮助函数。

最后，如果您决定没有其他好的选择，并且必须使用继承来实现所需的代码重用，那么您可以使用它，但是，请遵循P.A.I.L.限制继承的四条规则，以保持其正常。

将继承用作私有实现细节。不要公开您的基类，请为此使用接口。这使您可以根据自己的需要自由添加或删除继承，而无需进行重大更改。保持基类抽象。这使得将需要共享的逻辑与不共享的逻辑区分开来更加容易。隔离基础类和子类。不要让子类覆盖基类方法（使用策略模式），避免让它们期望财产/方法相互存在，使用其他形式的代码共享来实现这一点。使用适当的语言特性强制基类上的所有方法不可重写（在Java中为“final”，在C#中为非虚拟）。继承是最后的手段。

特别是“隔离”规则可能听起来有点难理解，但如果你自律，你会得到一些很好的好处。特别是，它让您可以自由地避免上面提到的与继承相关的所有主要令人讨厌的陷阱。

遵循代码要容易得多，因为它不会在基类/子类之间来回穿梭。如果您从未使任何方法可重写，则当您的方法在内部调用其他可重写方法时，不会意外泄漏。换句话说，您不会意外地破坏封装。脆弱的基类问题源于依赖意外泄漏的实现细节的能力。由于基类现在是孤立的，所以它不会比依赖于另一个via组合的类更脆弱。致命的死亡钻石不再是一个问题，因为根本不需要有多层继承。如果你有抽象基类B和C，它们都共享很多功能，只需将该功能从B和C中移出，并移入一个新的抽象基类类D。从B继承的任何人都应该更新为从B和D继承，从C继承的任何人均应该从C和D继承。由于你的基类都是私有实现细节，要弄清楚谁继承了什么，做出这些改变应该不会太难。

结论

我的主要建议是在这件事上动动脑筋。比什么时候使用继承更重要的是对继承及其相关利弊的直观理解，以及对其他可以用来代替继承的工具的良好理解（组合并不是唯一的选择。例如，策略模式是一个令人惊叹的工具，它经常被遗忘）。也许当您对所有这些工具都有了很好的、扎实的理解后，您会选择比我推荐的更频繁地使用继承，这是完全可以的。至少，您正在做出明智的决定，而不仅仅是使用继承，因为这是您知道如何做到这一点的唯一方法。

进一步阅读：

我写了一篇关于这一主题的文章，深入探讨并提供了示例。一个网页，讲述了继承所做的三种不同的工作，以及如何通过Go语言中的其他方式完成这些工作。将类声明为不可继承（例如，Java中的“final”）是很好的原因列表。乔舒亚·布洛赫（Joshua Bloch）的《有效的Java》（Effective Java）一书，第18项，讨论了组合而非继承，以及继承的一些危险。

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

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

公正的观点是，继承只应在以下情况下使用：

两个类都在同一逻辑域中子类是超类的适当子类型超类的实现对于子类是必要的或适当的子类所做的增强主要是附加的。

有时，所有这些东西都会汇聚在一起：

更高级别的域建模框架和框架扩展差分编程