Facade、Proxy、Adapter 和 Decorator 设计模式之间的区别？

Question

Facade、Proxy、Adapter和Decorator设计模式有什么区别？

从一般的角度来看，这些模式似乎做同样的事情，即：包装 API 并提供对其的访问。

如何区分这些图案？
如何辨别一种模式何时比其他模式更适合？

Answer 1

TL；博士

• 适配器：用于不兼容的接口
• Facade：用于使界面更简单
• Proxy：用于管理重型和/或复杂的对象
• 装饰器：用于在运行时扩展它

详细

适配器使给定的类/对象适应新的接口。对于前者，通常采用多重继承。在后一种情况下，该对象由一致的适配器对象包装并传递。

Facade 是通往一组复杂功能的简单网关。您制作了一个黑匣子，让您的客户减少担心。

Proxy 提供与代理类相同的接口，并且通常会自行完成一些内务处理工作。因此，您不必制作一个重对象的多个副本

X

，而是制作一个轻量级代理

P

的副本，后者反过来管理

X

并根据需要转换您的调用。

Decorator 用于为您的对象添加更多火药（注意术语“对象”——您通常在运行时动态装饰对象）。您不会隐藏/损害对象的现有接口，但是。

现在你已经涉及到装饰器了，你可能想知道为什么要强调对象这个词——一些语言（比如 Java）根本不允许虚拟继承（即像 C++ 那样的多重继承）来允许你在编译时间。

由于我们已经引入了多重继承（以及可怕的菱形），您将留意mixins——它们是接口的有序线性链接，以解决多重继承的问题。然而，mixin 的混合效果不太好。我们最终得到了traits——是的，那些无状态的行为小斑点，你总是在C++的模板参数中看到弹出窗口。 Traits 试图以优雅的方式解决行为的组合和分解问题，而不是多重继承或有序链接。

Answer 2

立面

例如，您可以使用外观来更轻松地调用 API。看一下远程外观的this示例。这里的想法是服务器上代码的完整实现对客户端是隐藏的。客户端调用 1 个 API 方法，该方法又可以在服务器上进行 1 个或多个 API 调用。

适配器

可以在维基百科上的这里找到一个很好的例子。客户端对象

Source

希望调用另一个对象

Target

上的方法，但另一个对象的接口与客户端期望的不同。

输入适配器对象。

它可以从

Source

对象进行调用，并在幕后调用应该使用的

Target

方法。

Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)

对于Proxy，我对这种设计模式没有任何经验。