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

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

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

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

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

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

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

继承的缺点：

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

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

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

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

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

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

Class Aircraft extends Engine{
  var wings;
}

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

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

Class Aircraft {
  var wings;
  var engine;
}

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