在Java或C#中，对象一旦实例化就不能更改其类型。

因此，如果您的对象需要显示为不同的对象或根据对象的状态或条件表现出不同的行为，那么请使用组合：参考状态和策略设计模式。

如果对象需要具有相同的类型，则使用继承或实现接口。

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

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

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

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

除了是/有一个考虑因素之外，还必须考虑对象必须经历的继承的“深度”。任何超过五或六级继承深度的内容都可能会导致意外的强制转换和装箱/拆箱问题，在这种情况下，编写对象可能是明智的。

这里没有找到满意的答案，所以我写了一个新的。

为了理解为什么“更喜欢组合而不是继承”，我们需要首先找回这个缩短的习惯用法中省略的假设。

继承有两个好处：子类型化和子类化

子类型化意味着符合类型（接口）签名，即一组API，并且可以覆盖部分签名以实现子类型化多态性。子类化意味着方法实现的隐式重用。

这两个好处带来了两个不同的继承目的：面向子类型和面向代码重用。

如果代码重用是唯一的目的，那么子类化可能会给一个比他所需要的更多的东西，即父类的一些公共方法对于子类来说没有多大意义。在这种情况下，不赞成组合而不是继承，而是要求组合。这也是“is-a”与“has-a”概念的由来。

因此，只有当有了子类型，即以后以多态的方式使用新类时，我们才会面临选择继承或组合的问题。这是在所讨论的缩短成语中被省略的假设。

To子类型要符合类型签名，这意味着组合必须始终公开不少于该类型的API数量。现在开始进行权衡：

继承提供了直接的代码重用（如果不被重写），而组合必须对每个API重新编码，即使这只是一个简单的委托工作。继承通过内部多态站点this提供了直接的开放递归，即在另一个成员函数中调用重写方法（甚至类型），无论是公共的还是私有的（尽管不鼓励）。开放递归可以通过组合来模拟，但它需要额外的努力，并且可能并不总是可行的（？）。对重复问题的回答也有类似之处。继承公开受保护的成员。这打破了父类的封装，如果被子类使用，则会引入子类和父类之间的另一个依赖关系。组合具有控制反转的特性，其依赖性可以动态注入，如装饰器模式和代理模式所示。组合具有面向组合器编程的优点，即以类似于组合模式的方式工作。编程到接口后立即进行组合。组合具有易于多重继承的优点。

考虑到上述权衡，我们因此更喜欢组合而不是继承。然而，对于紧密相关的类，即当隐式代码重用真正带来好处，或者需要开放递归的魔力时，继承应该是选择。

继承是非常诱人的，尤其是来自程序领域的继承，它通常看起来很优雅。我的意思是，我需要做的就是将这一点功能添加到其他类中，对吗？嗯，问题之一是继承可能是最糟糕的耦合形式

基类通过以受保护成员的形式向子类公开实现细节来打破封装。这会使您的系统变得僵化和脆弱。然而，更悲惨的缺陷是新的子类带来了继承链的所有包袱和观点。

《继承是邪恶的：DataAnnotationsModelBinder的史诗般的失败》一文在C#中讲述了一个这样的例子。它显示了继承在何时应该使用组合以及如何重构组合。

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

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

当我们说数字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）方法的行为已经明显改变，没有保留父类型的财产。从类的客户端的角度思考。他们可能会收到一组整数，其中需要一个整数列表。客户端可能希望添加一个值，并将该值添加到列表中，即使该值已经存在于列表中。但如果价值存在，她就不会有这种行为。她大吃一惊！

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

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