何时优先考虑继承而不是组合答案

【问题标题】：When to Favor Inheritance Over Composition何时优先考虑继承而不是组合
【发布时间】：2015-08-31 09:42:37
【问题描述】：

这个问题似乎是重复的，但事实并非如此。我用谷歌搜索，公共汽车无法获得概念上的清晰度。有很多动物，汽车类的例子。但是，我想了解基本逻辑。通常说，优先组合胜过继承，因为它提供了许多优点。在这种情况下，为什么提供继承作为 OOP 的主要概念之一。我的问题是什么时候更倾向于继承而不是组合？

【问题讨论】：

@Alex，是什么让您认为它更适合该论坛？ 程序员不是 Stack Overflow 上“不适合”问题的垃圾场。
@Alex 这个问题对于程序员来说可能会被关闭为“基于意见”或“过于宽泛”。
@Alex 这个问题非常不适合程序员 - 它会很快被否决并关闭，请参阅meta.programmers.stackexchange.com/questions/6483/… 推荐阅读：@987654322 @

【解决方案1】：

如果您使用的语言没有多重继承，则应该始终支持组合而不是继承。

在没有多重继承的语言（Java、C#、Visual Basic.NET）中，引入一个继承层次结构会自动将您排除在所有其他替代继承层次结构之外。在这些语言中，继承只会把你锁在里面。

使用组合，您可以做所有可以用继承做的事情，也可以做一些您不能用继承做的事情，例如，模拟多重继承。

让一个类实现多个接口本质上是从任何客户端的角度模拟多重继承。

组合一个具有多个依赖项的类本质上解决了从多个基类“继承”以实现可重用性的问题。

继承最初是作为一个概念包含在 OOP 中的，因为 OOP 最初是根据多重继承来描述的。参见例如Object-Oriented Software Construction，它用 Eiffel 来解释 OOP - 一种具有多重继承的编程语言。

【讨论】：

【解决方案2】：

总之，

如果是 is-a 关系，则使用继承。当它是 has-a 关系时使用组合。

只要没有任何变化，继承就完全没问题。但是当您以后倾向于扩展/修改类的行为时，您将面临很多继承问题。

您倾向于打破最初的假设，并且需要在很多地方进行更改。如果你使用合成，你可以避免所有这些修复。

【讨论】：

【解决方案3】：

我认为核心概念比改变、可维护性等更重要。在给定的情况下，A 关系是否比 Has A 关系更好？

推荐阅读：Gang Of Four 在开始讨论模式之前对类型、接口、OOP 等的讨论。

【讨论】：