Facade、Proxy、Adapter和Decorator设计模式有什么区别？ p>
从一般的角度来看，这样的模式似乎在做同样的事情，即：包装一个 API 并提供对它的访问。
如何区分这些模式？
如何辨别一种模式何时比其他模式更适合？
【问题讨论】：
标签： design-patterns proxy adapter decorator facade
Adapter 使给定的类/对象适应新的接口。在前者的情况下，通常采用多重继承。在后一种情况下，对象由符合要求的适配器对象包装并传递。我们这里要解决的问题是接口不兼容。
Facade 更像是通向一组复杂功能的简单网关。您为您的客户制作了一个黑匣子，以减少他们的担忧，即让界面更简单。
Proxy 提供与被代理类相同的接口，并且通常会自行完成一些内务处理。 （因此，不是制作重对象 X 的多个副本，而是制作轻量级代理 P 的副本，后者反过来管理 X 并根据需要翻译您的调用。）您正在解决客户端的问题，无需管理一个沉重和/或复杂的对象。
装饰器用于为您的对象添加更多火药（注意术语对象——您通常在运行时动态地装饰对象）。您不会隐藏/损害对象的现有接口，而是只是在运行时扩展它。
既然你已经涉及到装饰器，你可能想知道为什么强调对象这个词——一些语言（如 Java）根本不允许虚拟继承（即像 C++ 那样的多重继承）来允许你在编译时完成此操作。
由于我们引入了多重继承（以及可怕的菱形），您需要注意 mixins ——它们是有序的接口线性链接来解决问题的多重继承。但是，mixin 并不能很好地混合。我们最终得到了 traits —— 是的，那些无状态的小行为，你在 C++ 的模板参数中一直看到弹出窗口。 Traits 试图以优雅的方式解决行为的组合和分解问题，而不是用于多重继承或有序链。
【讨论】：
立面
例如，您可以使用外观来更轻松地调用 API。看看this 远程外观的示例。这里的想法是服务器上代码的完整实现对客户端是隐藏的。客户端调用 1 个 API 方法，而后者又可以在服务器上进行 1 个或多个 API 调用。
适配器
可以在 Wikipedia 上找到 here 的一个很好的例子。客户端对象Source 想调用另一个对象Target 的方法，但该对象的接口与客户端所期望的不同。
输入适配器对象。
它可以接受来自Source 对象的调用，并在幕后调用应该使用的Target 方法。
Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)
至于代理，我对这种设计模式没有任何经验。
【讨论】：