避免继承疯狂

Question

因此，我需要在现有框架中实现API。此API管理与外部服务器的交互。我一直有责任想出一种方法来创建一个易于重复的“模式”，这样如果人们在给定的框架中处理新项目，他们就会有一个简单的集成API的解决方案。

我的第一个想法是为框架的“主”类创建一个类来扩展它，它将提供与API交互所需的所有虚拟功能。然而，我的老板否决了这个，因为现有的框架是“遗产重”，他想避免增加疯狂。我显然不能封装我的API，因为这就是API本身应该做的事情，这样做可能会隐藏功能。

没有要求期货开发人员复制和粘贴我的例子，我该怎么办？

Answer 1

如果您的老板对继承有敌意，请尝试聚合。 （ Has-a 关系而不是继承的 is-a 关系。）假设您通过对象与相关API接口，也许您可​​以将该对象保留在属性中你的框架'main'类，所以你可以像main->whateverapi->doWhatever()那样与它进行交互。如果API不是对象实现的，或者您需要将特定于您的环境的许多功能加载到它上，那么这就意味着要创建属于该角色的自己的类，并且它需要与第三方API相关。是的，这基本上意味着您正在为API构建API。但是，聚合可以避免掩盖功能问题;即使您必须执行中间层，也可以将原始API公开为main->yourobject->originalapi，而不必担心遗留问题。

Answer 2

听起来像你的老板遇到问题的是框架部分。框架和API之间存在一个重要的区别，为了对框架进行编码，您必须对框架进行良好的理解以及它如何适应整体开发，更多的是整体视图，不应轻易添加到框架中。

另一方面，API只是你的应用程序/框架的接口，通常只是一个实用程序调用库，我看不出他在库中存在继承或聚合问题，在我看来，问题是在框架本身中创建额外的复杂性，即要求开发人员扩展框架的主类比创建一个人们可以调用的独立API库（如果他们选择）要繁琐，我愿意打赌如果图书馆本身包含继承，你的老板不会关心（实际上可能是支持）。

Answer 3

就像上面的混乱中的答案一样，我打算建议聚合作为继承的替代方案。您可以包装API并使其可以通过属性或依赖注入进行配置。

同样对于相关主题，请参阅我对“How do the Proxy, Decorator, Adaptor, and Bridge Patterns differ?”的回答，了解其他“包装”设计模式的失败。