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

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

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

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

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

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

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

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

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

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

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

你需要看看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。