我看没有人提到钻石问题，这可能是继承带来的。

总之，如果类B和C继承了a，并且都重写了方法X，而第四个类D继承了B和C，并且没有重写X，那么应该使用X D的哪个实现？

维基百科对这个问题中讨论的主题提供了一个很好的概述。

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

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

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

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

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

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

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

你什么时候可以用作文？

你可以一直使用合成。在某些情况下，继承也是可能的，并可能导致更强大和/或更直观的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关系（例如狗是狗），你就去继承。

另一方面，当你在两个班级（学生有课程）或（老师学习课程）之间有一种或某种形容词关系时，你选择了作文。

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

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