对象组合在继承

简介
从面向对象编程的初期，有使用（而不是滥用）继承的做法。许多开发人员舒适的定义与实施虚拟基类的通用代码的抽象类。这个概念背后的主要原因是使用覆盖功能，如果需要修改行为，并支持代码的重用。但这样做，他们在一段期间内的代码脆弱的基类开始有越来越多的虚拟未必要求其所有派生类的方法。在这篇文章中，我们首先会看到我们类设计中的组成的意思。我们将看到如何组成避免慢性，Äòobject污染问题？？不正确继承的副产品。本文介绍了使用WPF应用程序组成，但它可以很好地在他人使用以及。问题
让，AOS尝试创建一个系统，不同类型的用户（经理，编码器，及领袖）。所有用户都应该有打印机相关操作访问。系统应支持功能:打印，传真，扫描，电子邮件。
用户和打印机的功能之间的映射应该如下:经理:打印，传真，扫描，电子邮件负责人:打印，扫描编码器:打印组成的解决方案
，AOS尝试解决这个问题的组成如下。从上述问题的定义，我们可以想像一些软件实体和接口，可以在实施。接口:IPrinter，IEmployee类:SuperPrinter，AvergePrinter，BasicPrinter， 经理， 编码器，负责人
上述推论是纯交涉的角色和功能规范中定义的的行动。没有任何功能规范，你会发现作为一个插件，在用户操作的打印机的参考。但如果你仔细去通过规范，你可以想像接口？？代码> IPrinterEnabled？？，这将允许用户在施工时间，以堵塞混凝土打印机对象的财产公开打印机接口。
这种即插即用允许留为用户​​未来的变化灵活的系统可能会重新排列用户和打印机之间的关系。 （例如容许领导人使用SuperPrinter）
请参阅下面的类图，解释相同:{S0}
您也可以参考所附的WPF示例描绘它的实现。继承解决方案
我想解释我们如何与继承的方法来解决上述问题了。请注意该应用程序将表现为最终用户完全一样，浑然不觉的刚性系统发展变化。我唐，AOT要进入实施的描述，您可以检查对于理解类图和附加代码。
上述图和代码，你会发现，具体用户类已被打印机功能的额外知识污染。虽然他们可能会在内部使用的打印机对象将来电转接至适当的执行，使得开发商强制与基类来实施这些打印机签名，使他们这样就可以由派生类中重写虚拟或执行上的所有接口具体类。开发商普遍对基类的思维方法？？代码> IPrinterCommand？？接口随着时间的推移变化，他们只是需要建立适当的基类的虚方法。这是一个疯狂的闻到腐烂的设计错误，因为它需要修改现有的（AMP;工作）基类的源代码，并更新所有派生类的具体变化而定。结论
正如您所看到，这两个方法有几个常见的类，但在用户类的微妙变化是使用打印机的功能。在继承的方法，打印机的功能继承到派生的用户对象，显示用户和打印功能之间的紧耦合。而在组成，用户类别，启用打印机，让他们继承？？代码> IPrinterEnabled？？接口，使得开发作为一个插件在用户对象分配打印机功能的优势。我们可以很说，在构成方法的用户对象是没有打印功能的污染。
注:我用上面的例子，作为一个随机的情况下。这可能不是一个实际的场景。由于听力疯狂的要求，所有开发人员都使用的事实，赢得了这个例子，AOT驱动你疯了。历史2011年5月1日:初始版本