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

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

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

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

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

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

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

我听过的一条经验法则是，当它是一种“is-A”关系时，应该使用继承；当它是“has-A”关系的时候，应该使用组合。尽管如此，我觉得你应该始终倾向于构图，因为它消除了很多复杂性。

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

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

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

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

正如许多人所说的，我首先要检查是否存在“是”的关系。如果存在，我通常检查以下内容：

是否可以实例化基类。也就是说，基类是否可以是非抽象的。如果可以是非抽象的，我通常更喜欢写作

例如1。会计是员工。但我不会使用继承，因为Employee对象可以实例化。

例如2。书籍是SellingItem。SellingItem无法实例化-它是抽象概念。因此，我将使用遗传痤疮。SellingItem是一个抽象基类（或C#中的接口）

你觉得这种方法怎么样？

此外，我支持为什么要使用继承？

使用继承的主要原因不是作为组合的一种形式，而是为了让您可以获得多态行为。如果不需要多态性，那么可能不应该使用继承。

@马修。在https://softwareengineering.stackexchange.com/questions/12439/code-smell-inheritance-abuse/12448#comment303759_12448

继承的问题在于它可以用于两个正交的目的：接口（用于多态性）实现（用于代码重用）

参考

哪个班级设计更好？继承与聚合

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