“优先考虑组成而不是继承” 只是一种很好的启发式方法
您应该考虑上下文，因为这不是通用规则。不要将其表示可以进行合成时不要使用继承。如果是这样，您可以通过禁止继承来解决它。
我希望在本文中阐明这一点。
我不会尝试捍卫构图的优点。我认为这是题外话。取而代之的是，我将讨论开发人员可能考虑使用合成更好的继承的某些情况。关于这一点，继承有其自身的优点，我也认为这是不合时宜的。
车辆实例
我写的是关于出于叙述目的而尝试以愚蠢的方式进行开发的开发人员
让我们去的经典例子变体，一些OOP的课程使用......我们有一个Vehicle类，那么我们得到Car，Airplane，Balloon和Ship。
注意：如果需要以本示例为基础，请假装这些是视频游戏中的对象。
然后Car，Airplane可能会有一些通用的代码，因为它们都可以在陆地上滚动。开发人员可以考虑为此在继承链中创建一个中间类。但是，实际上在Airplane和之间也有一些共享代码Balloon。他们可以考虑为此在继承链中创建另一个中介类。
因此，开发人员将寻找多重继承。在开发人员正在寻求多重继承的时候，设计已经出错了。
最好将此行为建模为接口和组合，因此我们可以重用它，而不必遇到多个类继承。例如，如果开发人员创建FlyingVehicule类。他们会说这Airplane是一个FlyingVehicule（类继承），但我们可以改为说，Airplane有一个Flying组件（组成），并Airplane是一个IFlyingVehicule（接口继承）。
使用接口，如有必要，我们可以拥有（接口的）多重继承。另外，您没有耦合到特定的实现。提高代码的可重用性和可测试性。
请记住，继承是实现多态的工具。另外，多态性是可重用性的工具。如果可以通过使用组合来提高代码的可重用性，则可以这样做。如果不确定组合是否提供了更好的可重用性，则“优先使用组合而不是继承”是一种很好的试探法。
所有这一切不用说了Amphibious。
实际上，我们可能不需要一些破土动工的东西。斯蒂芬到Hurn在他的文章“青睐成分在继承”更雄辩例如第1部分和第2部分。
替代性和封装
应该A继承还是撰写B？
如果AIs的一个专业化B应该满足Liskov替换原则，则继承是可行的，甚至是可取的。如果存在A无法有效替代的情况，B则我们不应使用继承。
为了保护派生类，我们可能对作为防御性编程形式的组合感兴趣。特别是，一旦您开始将其B用于其他不同目的，可能会面临更改或扩展它以使其更适合于这些目的的压力。如果存在B可能暴露可能导致无效状态的方法的风险，A我们应该使用组合而不是继承。即使我们都是笔者B和A，这是一回事少操心，因此组成简化的可重用性B。
我们甚至可以认为，如果在功能B是A不需要（和我们不知道，如果这些功能可能会导致一个无效的状态A，无论是在本实现或将来），这是一个好主意，使用的组合物而不是继承。
组合还具有允许切换实现并简化模拟的优点。
注意：在某些情况下，尽管替换有效，但我们仍要使用合成。我们通过使用接口或抽象类（当一个主题时使用的是另一主题）来归档该可替代性，然后将组合与实际实现的依赖项注入结合使用。
最后，当然，有一个论点是我们应该使用组合来捍卫父类，因为继承会破坏父类的封装：
继承向子类公开其父级实现的详细信息，通常说“继承破坏封装”
-设计模式：可重用的面向对象软件的要素，四个组成部分
好吧，那是一个设计不良的父类。这就是为什么您应该：
为继承而设计，或禁止继承。
-有效的Java，Josh Bloch
溜溜球问题
组成有帮助的另一种情况是溜溜球问题。这是来自维基百科的报价：
在软件开发中，溜溜球问题是一种反模式，当程序员必须阅读和理解其继承图非常长且复杂以至于程序员必须在许多不同的类定义之间进行切换时，它才会发生程序的控制流程。
您可以解决，例如：您的类C不会从class继承B。相反，您的类C将具有type的成员A，该成员可能是（也可能不是）type的对象B。这样，您将不会针对的实现细节进行编程B，而是针对（of）接口A提供的契约进行编程。
反例
许多框架都倾向于继承而不是组合（这与我们所争论的相反）。开发人员之所以会这样做，是因为他们在基类中进行了大量工作，因为使用基类进行实现会增加客户端代码的大小。有时这是由于语言的限制。
例如，PHP ORM框架可以创建一个基类，该基类使用魔术方法来允许编写代码，就像对象具有真实属性一样。取而代之的是，使用magic方法处理的代码将进入数据库，查询特定的请求字段（可能将其缓存以备将来使用）并返回它。用合成来做到这一点将需要客户端为每个字段创建属性或编写魔术方法代码的某些版本。
附录：还有其他一些方法可以允许扩展ORM对象。因此，我认为在这种情况下不需要继承。这更便宜。
对于另一个示例，视频游戏引擎可以根据目标平台创建使用本机代码的基类，以进行3D渲染和事件处理。此代码很复杂，且特定于平台。实际上，这是引擎的开发人员用户处理该代码的代价，并且容易出错，这就是使用引擎的部分原因。
此外，如果没有3D渲染部分，这就是有多少小部件框架可以工作。这使您不必担心处理OS消息……实际上，在许多语言中，如果没有某种形式的本机出价，就无法编写此类代码。而且，如果您要这样做，则会使您的便携性变得更严格。相反，只要开发人员不破坏兼容性（太多），就可以继承。您将来可以轻松地将代码移植到它们支持的任何新平台。
另外，请考虑很多次，我们只想覆盖一些方法，而将其他所有方法保留为默认实现。如果我们一直使用组合，就必须创建所有这些方法，即使仅委派给包装的对象也是如此。
通过这种说法，在某种程度上，对于可维护性而言，组合可能比继承最糟糕（当基类过于复杂时）。但是，请记住，继承的可维护性可能比组合的可维护性差（当继承树太复杂时），这就是我在溜溜球问题中所指的。
在给出的示例中，开发人员很少打算在其他项目中重用通过继承生成的代码。这减轻了使用继承而不是合成的可重用性的降低。另外，通过使用继承，框架开发人员可以提供许多易于使用和易于发现的代码。
最后的想法
如您所见，在某些情况下（并非总是如此），组合比继承具有某些优势。重要的是要考虑环境和所涉及的不同因素（例如可重用性，可维护性，可测试性等）来做出决定。回到第一点：“宁要继承组成”是一个刚刚好的启发。
您可能还注意到，我描述的许多情况都可以在某些程度上用“特质”或“混合蛋白”解决。可悲的是，这些功能不是大量语言中的通用功能，通常会带来一些性能损失。值得庆幸的是，他们流行的堂兄扩展方法和默认实现减轻了某些情况。
我在最近的一篇文章中谈论了接口的一些优点，这就是为什么我们需要C＃中的UI，Business和Data访问之间的接口。您可能会感兴趣，它有助于解耦并简化可重用性和可测试性。