当您想要“复制”/公开基类的API时，可以使用继承。当您只想“复制”功能时，请使用委派。

其中的一个例子是：您想要从列表中创建堆栈。堆栈只有pop、push和peek。考虑到堆栈中不需要push_back、push_front、removeAt等功能，您不应该使用继承。

在可以枚举不变量的情况下，子类型更合适，功能更强大，否则使用函数组合实现可扩展性。

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

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

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

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

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

继承是一种非常强大的代码重用机制。但需要正确使用。如果子类也是父类的子类型，我会说继承是正确使用的。如上所述，利斯科夫替代原则是这里的关键点。

子类与子类型不同。您可以创建不是子类型的子类（此时应该使用组合）。为了理解什么是子类型，让我们开始解释什么是类型。

当我们说数字5是整数类型时，我们说明5属于一组可能的值（例如，请参阅Java原语类型的可能值）。我们还声明，我可以对值执行一组有效的方法，如加法和减法。最后，我们要说明的是，有一组财产总是可以满足的，例如，如果我将值3和5相加，结果会得到8。

举另一个例子，考虑抽象数据类型，整数集合和整数列表，它们可以保存的值仅限于整数。它们都支持一组方法，如add（newValue）和size（）。而且它们都有不同的财产（类不变量），Sets不允许重复，而List允许重复（当然还有它们都满足的其他财产）。

子类型也是一种类型，它与另一种类型（称为父类型（或父类型））有关系。子类型必须满足父类型的功能（值、方法和财产）。这种关系意味着在任何期望超类型的上下文中，它都可以被子类型替代，而不会影响执行的行为。让我们去看一些代码来举例说明我在说什么。假设我写了一个整数列表（用某种伪语言）：

class List {
  data = new Array();

  Integer size() {
    return data.length;
  }

  add(Integer anInteger) {
    data[data.length] = anInteger;
  }
}

然后，我将整数集合写成整数列表的子类：

class Set, inheriting from: List {
  add(Integer anInteger) {
     if (data.notContains(anInteger)) {
       super.add(anInteger);
     }
  }
}

我们的整数集合类是整数列表的子类，但不是子类型，因为它不满足列表类的所有特性。满足了方法的值和签名，但不满足财产。add（Integer）方法的行为已经明显改变，没有保留父类型的财产。从类的客户端的角度思考。他们可能会收到一组整数，其中需要一个整数列表。客户端可能希望添加一个值，并将该值添加到列表中，即使该值已经存在于列表中。但如果价值存在，她就不会有这种行为。她大吃一惊！

这是一个不正确使用继承的典型例子。在这种情况下使用合成。

（片段来自：正确使用继承）。

我的经验法则是：在使用继承之前，考虑组合是否更有意义。

原因：子类化通常意味着更复杂和更紧密，即更难在不出错的情况下进行更改、维护和扩展。

Sun的Tim Boudreau给出了一个更完整、更具体的答案：

在我看来，使用继承的常见问题是：无辜的行为可能会产生意想不到的结果——这方面的经典例子是调用超类中的可重写方法构造函数，在子类实例字段初始化。在一个完美的世界里，没有人会这样做。这是不是一个完美的世界。它给子类提供了不正当的诱惑，让它们对方法调用的顺序等做出假设——这种假设往往不会如果超类可以随着时间的推移而发展，那么它是稳定的。另请参见我的烤面包机和咖啡壶类比。类变得更重了——你不一定知道你的超类在其构造函数中做了什么工作，或者它需要多少内存使用。因此，构建一些无辜的轻量级对象可以比你想象的要贵得多，如果超类进化它鼓励子类的爆炸。类加载需要时间，更多的类需要内存。在你与NetBeans规模的应用程序打交道，但在那里，我们有了真正的例如，由于第一次显示菜单触发了大量的类加载。我们通过移动到更多的声明性语法和其他技术，但这需要花费时间修复。这使得以后改变事情变得更加困难——如果你公开了一个类，那么交换超类会破坏子类-这是一个选择，一旦你公开了代码，你就结婚了所以如果你不改变你的真实功能超类，如果你使用，而不是扩展你需要的东西。例如，子类化JPanel-这通常是错误的；如果子类是在公共场所，你永远不会有机会重新审视这个决定。如果它作为JComponent getThePanel（）访问，您仍然可以这样做（提示：将组件的模型作为API公开）。对象层次结构不可缩放（或使其稍后缩放比提前规划要困难得多）-这是经典的“太多层”问题我将在下面讨论AskTheOracle模式如何解决它（尽管它可能冒犯OOP纯粹主义者）。...如果你允许继承遗产，我会怎么做带着一粒盐是：永远不显示字段，常量除外方法应为抽象方法或最终方法不从超类构造函数调用任何方法...所有这些都不适用于小型项目，而适用于大型项目私人课程比公共课程

简而言之，我同意“比起继承，我更喜欢成分”，但对我来说，这听起来常常像“比起可口可乐，我更爱土豆”。有继承的地方，也有合成的地方。你需要了解差异，然后这个问题就会消失。这对我来说真正的意义是“如果你要使用继承——再想想，你很可能需要复合”。

当你想吃的时候，你应该更喜欢土豆而不是可口可乐，当你想喝的时候，应该更喜欢可口可乐而不是土豆。

创建子类不仅仅意味着调用超类方法的便捷方式。当子类在结构上和功能上都是一个超级类时，您应该使用继承，因为它可以用作超级类，并且您将使用它。如果不是这样的话，那不是继承，而是其他东西。合成是指你的对象由另一个组成，或者与它们有某种关系。

所以对我来说，如果有人不知道自己是否需要继承或组成，真正的问题是他不知道自己是想喝酒还是想吃饭。多想想你的问题领域，更好地理解它。