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

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

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

Class Aircraft extends Engine{
  var wings;
}

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

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

Class Aircraft {
  var wings;
  var engine;
}

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

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

我的上述酸性测试是：

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

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

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

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

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

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

Why?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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