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

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

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

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

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

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

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

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

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

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

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

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

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

继承优势：

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

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

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

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

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

Why?

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

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

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

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

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

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

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

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