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

继承优势：

它建立了逻辑“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();
     }
} 

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

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

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

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

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

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

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

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

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

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

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

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

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

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