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

继承优势：

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

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

Class Aircraft extends Engine{
  var wings;
}

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

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

Class Aircraft {
  var wings;
  var engine;
}

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

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

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

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

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

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

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

这完全取决于实体关系。

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

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

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

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