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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

你觉得这种方法怎么样？

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

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

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

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

参考

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