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

理解这一点的一个简单方法是，当您需要类的对象与其父类具有相同的接口时，应该使用继承，这样它就可以被视为父类的对象（上广播）。此外，派生类对象上的函数调用在代码中的任何地方都保持不变，但要调用的特定方法将在运行时确定（即，低级实现不同，高级接口保持不变）。

当您不需要新类具有相同的接口时，即您希望隐藏该类的用户不需要知道的类实现的某些方面时，应使用组合。因此，组合更多的是支持封装（即隐藏实现），而继承意味着支持抽象（即提供某种东西的简化表示，在这种情况下，相同的接口用于具有不同内部结构的一系列类型）。

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

我的上述酸性测试是：

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

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

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

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

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

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

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

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

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

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

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