“有利于组成而不是继承”的概念从何而来？

#1 楼

尽管我认为我早在GoF之前就已经听说过关于合成与继承的讨论，但我不能指责某个特定来源。可能一直是Booch。 >它由一位备受尊敬的消息人士提供详细的解释和论点，他将流行语创造出来，以提醒人们最初的复杂讨论。

它与已知的部分知识共享-俱乐部会眨眨眼的时间，通常在评论n00b错误时
很快就会被成千上万的人盲目地重复，他们从未读过解释，但是喜欢以此为借口而不去思考并且作为一种便宜而又容易超越他人的方式
，最终，没有任何合理的揭穿可以阻止“模因”浪潮-范式退化为宗教和教条。

模因原本旨在使n00bs启蒙的现在被用作俱乐部以盲目迷惑他们。

组成和继承是完全不同的东西，不应与ea混淆其他。确实可以通过很多额外的工作来使用合成来模拟继承，但这不会使继承成为二等公民，也不会使合成成为喜欢的儿子。许多n00b尝试将继承用作快捷方式这一事实并不会使该机制失效，并且几乎所有n00b都将从错误中吸取教训，从而进行了改进。

请考虑一下您的设计，并停止喷出口号。

#2 楼

经验。

就像您说它们是用于不同工作的工具一样，但之所以出现这个短语，是因为人们没有以这种方式使用它。但是有些人试图将其用作重用/共享代码的方式，这在后来的危险中非常多。基本原理是“如果我继承就可以了，那么我就可以免费获得所有方法”，但是却忽略了这两个类可能没有多态关系的事实。类之间的关系通常不是多态的。它的存在只是为了提醒人们不要通过继承来屈膝回应。

#3 楼

这不是一个新主意，我相信它实际上是在1994年出版的GoF设计模式书中引入的。

继承的主要问题是白盒子。根据定义，您需要知道要继承的类的实现细节。另一方面，通过组合，您只关心正在编写的类的公共接口。

从GoF书中：


继承公开作为其父级实现的详细信息的子类，通常会说“继承破坏封装”。

#4 楼

为了回答您的部分问题，我相信这个概念首先出现在1994年首次出版的《 GOF设计模式：可重用的面向对象软件的元素》一书中。该短语出现在第20页的开头，引言：


赞成对象组成优于继承


他们在此声明的开头对继承与组成作了简要比较。他们不说“从不使用继承”。

#5 楼

“继承之上的构成”是一种简短的（显然是误导性的）说法，“当感觉到某个类的数据（或行为）应被合并到另一个类中时，请务必在盲目应用继承之前考虑使用组合”。
为什么会这样呢？因为继承会在两个类之间创建紧密的编译时耦合。相比之下，组合是松散的耦合，其中包括使关注点清晰分离，在运行时切换依赖关系的可能性以及更容易，更独立的依赖关系可测试性。

这仅意味着继承应谨慎处理，因为是有代价的，并不是说它没有用。实际上，“组成继承”通常最终是“组成+继承继承”，因为您通常希望组合的依赖关系是抽象的超类而不是具体的子类本身。它使您可以在运行时在依赖项的不同具体实现之间进行切换。出于这个原因（除其他原因外），您可能会看到继承以接口实现或抽象类的形式使用的频率比原始继承。

一个比喻的例子可能是：

“我有一个Snake类，我想将Snake叮咬时发生的事情作为该类的一部分。我很想让Snake继承一个具有Bite（）方法的BiterAnimal类，并重写该方法以反映有毒咬但是，继承之上的合成警告我应该改为使用合成...就我而言，这可能会转化为具有Bite成员的Snake。Bite类可以是抽象的（或接口），具有多个子类。我有一些不错的事情，例如拥有VenomousBite和DryBite子类，并且能够随着蛇的年龄的增长而改变同一Snake实例上的叮咬。另外，在单独的类中处理Bite的所有影响可以使我在该Frost类中重用，因为霜冻咬人但不是BiterAnimal，依此类推...”

#6 楼

有关组合的一些可能参数：

与语言/框架无关的组合
继承和它强制执行/要求/启用的内容在语言上就子/超类可以访问的内容而有所不同以及它对虚拟方法等的性能影响。组成是非常基本的，几乎不需要语言支持，因此跨不同平台/框架的实现可以更轻松地共享组成模式。

组成是非常构建对象的简单而触觉的方式
继承相对容易理解，但在现实生活中仍然不那么容易展示。现实生活中的许多对象都可以分解为多个部分并组成。假设可以使用两个轮子，框架，座椅，链条等来制造自行车。在继承隐喻中，您可以说自行车延伸了单轮脚踏车，虽然可行，但比实际构图要远得多（显然这不是很好的继承示例，但要点仍然相同）。甚至“继承”一词（至少我希望大多数美国英语使用者会想到）也会自动按照“已故亲戚传来的东西”的方式调用含义，这与软件中的含义有一定的关联，但仍然很松散。

合成几乎总是更灵活
使用合成，您始终可以选择定义自己的行为，也可以只暴露组成部分的那一部分。这样，您就不会面临继承层次结构（虚拟与非虚拟等）可能施加的任何限制。

因此，这可能是因为Composition自然是一个较简单的隐喻，理论上较少约束比继承。此外，这些特殊原因在设计时可能更明显，或者在处理继承的某些痛点时可能会突出。

免责声明：
显然不是这条清晰的路/单向路。每个设计都应评估几种模式/工具。继承被广泛使用，具有很多好处，而且很多时候比合成更优雅。这些只是人们偏爱构图时可能会使用的一些可能原因。

评论

---

“显然，这不是一条清晰的路/一条路。”什么时候组成不比继承灵活（或同等）？我会说那是一条单向街。对于特殊情况，继承只是语法糖。

–weberc2
2015年12月12日下午4:05

---

当使用通过显式实现的接口实现合成的语言时，合成通常不灵活，因为不允许这些接口随着时间的过去以向后兼容的方式进行发展。 #jmtcw

– MikeSchinkel
19年5月10日在21:53

---

#7 楼

也许您刚刚注意到最近几个月有人在说这个，但是对于优秀的程序员而言，知道它的时间要长得多。我肯定已经说了大约十年了。

这个概念的重点是继承有很大的概念开销。当您使用继承时，则每个单个方法调用中都隐含有一个调度。如果您有深层继承树，或者有多个调度，或者两者都有（甚至更糟），那么弄清楚特定方法在任何特定调用中将调度到的位置都可以成为皇家PITA。它使对代码的正确推理变得更加复杂，并且使调试更加困难。

让我举一个简单的例子来说明。假设在继承树的深处，有人将方法命名为foo。然后其他人出现并在树的顶部添加foo，但是做了一些不同的事情。 （这种情况在多重继承中更为常见。）现在，在根类中工作的人破坏了晦涩的子类，并且可能没有意识到。您可能具有100％的单元测试覆盖率，而不会注意到这种破坏，因为最顶层的人不会考虑测试子类，而针对子类的测试不会考虑测试在顶层创建的新方法。 （诚​​然，有一些方法可以编写单元测试来解决这一问题，但是在某些情况下，您不能轻易地以这种方式编写测试。）相比之下，当您使用合成时，通常在每次呼叫时都将呼叫分配到的对象更加清楚。 （好吧，如果您正在使用控制倒置（例如，依赖注入），那么弄清调用的位置也可能会遇到问题。但是通常更容易弄清楚。）这使得推理起来更容易。作为奖励，组成会导致方法彼此分离。上面的示例不应在那里发生，因为子类将移至一些晦涩的组件，并且对foo的调用是用于晦涩的组件还是主要对象从来没有疑问。

现在您绝对正确，继承和组合是服务两种不同类型事物的两个非常不同的工具。当然，继承会带来概念上的开销，但是，当继承是工作的正确工具时，它所承担的概念上的开销要比不使用继承并手动执行为您做的事情要少。没有人知道他们在做什么，不会说您永远不要使用继承。但是请确保这是正确的做法。

不幸的是，许多开发人员了解了面向对象的软件，了解了继承，然后尽可能多地使用他们的新斧头。这意味着他们在组合是正确的工具的情况下尝试使用继承。希望他们能够及时学习，但是经常不会出现这种情况，直到四肢被移开等等。事先告诉他们这是一个坏主意，这会加快学习过程并减少伤害。

#8 楼

梅森（Mason）在评论中提到，有一天我们将谈论被认为有害的继承。

我希望如此。

继承的问题立刻变得简单，致命的是，它不尊重一个概念应该具有一种功能的想法。

在大多数OO语言中，当从基类继承时，您：从其接口继承
从其实现继承（包括数据和方法）

这会带来麻烦。语言大多受困于此。幸运的是，接口/抽象类存在于其中。按组成，委派大多数方法调用？但是，这样做会好得多，如果在界面中突然弹出一种新方法，并且不得不自觉选择如何实现它，甚至会被警告。

相反，Haskell仅当从纯接口（称为概念）“派生”时才允许使用Liskov原理（1）。您不能从现有的类派生，只有组合允许您嵌入其数据。

（1）概念可能为实现提供合理的默认值，但是由于它们没有数据，因此该默认值只能是根据概念提出的其他方法或常量进行定义。

#9 楼

这是对OO初学者在不需要时倾向于使用继承的观察结果的反应。继承当然不是一件坏事，但它可能会被滥用。如果一个类只需要另一个类的功能，那么组合可能会起作用。在其他情况下，继承将起作用，并且合成将不起作用。

从类继承意味着很多事情。这意味着派生类型是基数的一种（有关血腥细节，请参见Liskov替换原理），因为只要您使用基数，就应该使用派生。它为Derived提供对Base的受保护成员和成员功能的访问。这是一个紧密的关系，这意味着它具有很高的耦合性，对一个进行更改很可能需要对另一个进行更改。它使程序更难以理解和修改。在其他条件相同的情况下，您应该始终选择耦合程度较小的选项。

因此，如果合成或继承都可以有效地完成工作，请选择合成，因为它的耦合度较低。如果合成不能有效地完成工作，而继承会有效，则选择继承，因为您必须这样做。

#10 楼

这是我的两分钱（超出已经提出的所有要点）：

恕我直言，这归结为这样一个事实，即大多数程序员并没有真正获得继承，最终过度地继承了继承这个概念的教导结果。这个概念的存在是一种试图阻止他们过度使用的方法，而不是着重于教会他们如何正确地做。 ，尤其是对于具有其他范例经验的新开发人员：

这些开发人员最初认为继承是一个令人恐惧的概念。因此，它们最终会创建具有接口重叠的类型（例如，没有共同的子类型的相同指定行为），并且具有用于实现共同的功能块的全局变量。了解继承的好处，但是通常将其作为重用的万能解决方案进行教授。他们最终以为任何共享行为都必须通过继承来共享。这是因为重点通常是实现继承而不是子类型化。

在80％的情况下就足够了。但是另外20％是问题开始的地方。为了避免重写并确保他们利用了共享实现的优势，他们开始围绕预期的实现而不是底层抽象设计其层次结构。 “堆栈从双链表继承”就是一个很好的例子。

此时，大多数老师并不坚持引入接口的概念，因为它是另一个概念，或者是因为C ++），您必须使用抽象类和多重继承来伪造它们，这在现阶段还没有讲授。在Java中，许多老师并没有从接口的重要性中区分“没有多重继承”或“多重继承是邪恶的”。

所有这些都因以下事实而变得更加复杂：我们已经了解了不必编写带有实现继承的多余代码的种种美感，以至于大量直接的委托代码看起来是不自然的。因此组合看起来很混乱，这就是为什么我们需要这些经验法则来促使新程序员无论如何都要使用它们（它们也会过分使用）。

#11 楼

简单的答案是：继承比组合具有更大的耦合。给定两个质量相同的选项，请选择耦合性较小的一个。

#12 楼

我认为这种建议就像说“宁愿驾驶而不愿飞行”。也就是说，飞机比汽车具有各种优势，但这带来了一定的复杂性。因此，如果许多人尝试从市中心飞往郊区，那么他们真正需要听到的建议就是他们不需要飞行，而且从长远来看，飞行只会使事情变得更加复杂，即使在短期内看起来很酷/高效/容易。而当您确实需要飞行时，通常应该是显而易见的。

同样，继承可以完成合成无法完成的工作，但您应该在需要时使用它，而不是在不需要时使用它。 t。因此，如果您从未尝试过仅在不需要时就假定需要继承，那么您就不需要“更喜欢合成”的建议。但是很多人确实需要，而且确实需要这样的建议。另外，史蒂文·洛（Steven Lowe）的答案。真的，真的。

#13 楼

继承并不是天生的坏，组合也不是天生的好。它们只是OO程序员可以用来设计软件的工具。

当您查看一个类时，它做的事情是否比它绝对应该做的（SRP）还多？它是否不必要地复制了功能（DRY），还是对其他类的属性或方法过于感兴趣（功能嫉妒）？如果阶级违反了所有这些概念（甚至更多），那么它是否试图成为上帝阶级。这些是设计软件时可能发生的许多问题，这些问题都不一定是继承问题，但是在多态性也被应用的情况下，它们可能很快造成严重的麻烦和脆弱的依赖关系。

问题可能是缺少对继承的了解，或者是在设计方面的错误选择，或者可能是没有认识到与不遵循单一职责原则的类有关的“代码异味”。多态性和Liskov取代不必为了组成而被丢弃。多态性本身可以在不依赖继承的情况下应用，这些都是相当互补的概念。如果周到地应用。诀窍是为了使您的代码简单，整洁，并且不屈服于过于担心为了创建可靠的系统设计而需要创建的类的数量。

就偏重于继承而不是继承的问题而言，这实际上只是精心设计应用设计元素的另一种情况，这些设计元素对于要解决的问题最有意义。如果您不需要继承行为，那么您可能不应该这样做，因为合成将有助于避免不兼容和以后的重大重构工作。另一方面，如果您发现您正在重复很多代码，使得所有重复都集中在一组相似的类上，则可能是创建一个共同的祖先将有助于减少相同的调用和类的数量。您可能需要在每个课程之间重复。因此，您赞成组合，但是您并没有假设继承永远都不适用。

#14 楼

我相信，实际的报价来自Joshua Bloch的“ Effective Java”，其中是各章之一的标题。他声称继承在包中是安全的，无论是在专门设计和记录扩展类的任何地方。正如其他人指出的那样，他声称继承会破坏封装，因为子类取决于其超类的实现细节。他说，这导致了脆弱性。