你需要看看Bob叔叔的SOLID类设计原则中的Liskov替换原则。：）

你什么时候可以用作文？

你可以一直使用合成。在某些情况下，继承也是可能的，并可能导致更强大和/或更直观的API，但组合始终是一种选择。

什么时候可以使用继承？

人们常说，如果“bar是foo”，那么bar类可以继承foo类。不幸的是，仅此测试并不可靠，请改用以下方法：

bar是foo，AND酒吧可以做foos所能做的一切。

第一个测试确保Foo的所有getter在Bar中都有意义（=共享的财产），而第二个测试确保所有Foo的setter都在Bar（=共享功能）中有意义。

示例：狗/动物

狗是一种动物，狗可以做动物所能做的一切（如呼吸、移动等）。因此，狗类可以继承动物类。

反例：圆/椭圆

圆是椭圆，但圆不能做椭圆所能做的一切。例如，圆不能拉伸，而椭圆可以拉伸。因此，Circle类不能继承Ellipse类。

这被称为圆椭圆问题，这并不是一个真正的问题，但更多的是表明“一个条就是一个foo”本身不是一个可靠的测试。特别是，这个例子强调了派生类应该扩展基类的功能，而不是限制它。否则，基类不能以多态的方式使用。添加测试“bar可以做foos所能做的一切”确保了多态性的使用是可能的，这相当于Liskov替换原则：

使用基类指针或引用的函数必须能够在不知道的情况下使用派生类的对象

什么时候应该使用继承？

即使你可以使用继承，也不意味着你应该这样做：使用组合总是一种选择。继承是一个强大的工具，允许隐式代码重用和动态分派，但它确实有一些缺点，这就是为什么组合经常被首选的原因。继承和组合之间的权衡并不明显，在我看来，在lcn的回答中可以得到最好的解释。

作为经验法则，当多态性使用被认为非常普遍时，我倾向于选择继承而不是组合，在这种情况下，动态分派的功能可以导致更可读和更优雅的API。例如，在GUI框架中有一个多态类Widget，或者在XML库中有一种多态类Node，这样就可以使用一个比纯基于组合的解决方案更易读、更直观的API。

继承是非常强大的，但你不能强迫它（参见：圆-椭圆问题）。如果你真的不能完全确定一个真正的“is-a”子类型关系，那么最好是组合。

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

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

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

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

Why?

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

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

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

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

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

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

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

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

继承在子类和超级类之间建立了牢固的关系；子类必须了解超级类的实现细节。创建超级类要困难得多，因为你必须考虑如何扩展它。您必须仔细记录类不变量，并说明其他可重写方法在内部使用的方法。

如果层次结构真的代表了一种is-a-关系，那么继承有时是有用的。它与开放-封闭原则有关，该原则规定类应该封闭以进行修改，但开放以进行扩展。这样你就可以拥有多态性；需要一个处理超类型及其方法的泛型方法，但通过动态调度调用子类方法。这是灵活的，有助于创建间接，这在软件中是必不可少的（对实现细节了解较少）。

然而，继承很容易被过度使用，并且会产生额外的复杂性，导致类之间存在硬依赖关系。此外，由于层和方法调用的动态选择，很难理解程序执行过程中发生的事情。

我建议使用作曲作为默认设置。它更加模块化，并提供了后期绑定的好处（您可以动态更改组件）。另外，单独测试这些东西更容易。如果您需要使用类中的方法，则不必强制使用某种形式（Liskov替换原则）。

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

Class Aircraft extends Engine{
  var wings;
}

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

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

Class Aircraft {
  var wings;
  var engine;
}

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