Facade、Proxy、Adapter 和 Decorator 设计模式之间的区别？
Facade、Proxy、Adapter 和 Decorator 设计模式之间有什么区别？
从一般的角度来看，此类模式似乎做同样的事情，即：包装 API 并提供对其的访问。
如何区分这些模式？
如何辨别一种模式何时比其他模式更适合？
What is the difference between the Facade, Proxy, Adapter, and Decorator design patterns?
From a generic point of view, such patterns seem to do the same thing, that is: wrap an API and provide access to it.
How to distinguish these patterns?
How to discern when one pattern suits more than the others?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
TL;DR
详细的
适配器使给定的类/对象适应新的接口。对于前者，通常采用多重继承。在后一种情况下，对象由一致的适配器对象包装并传递。
Facade 是通向一组复杂功能的简单门户。您为您的客户制作了一个黑匣子，以减少他们的担忧。
Proxy 提供与代理类相同的接口，并且通常会自己完成一些内务处理工作。因此，您不必制作重对象
X的多个副本，而是制作轻量级代理P的副本，后者依次管理X并转换您的调用根据需要。装饰器用于为您的对象添加更多火药（注意术语“对象”——您通常在运行时动态装饰对象）。您不会隐藏/损害对象的现有接口，但是。
现在您已经涉及到装饰器了，您可能想知道为什么要强调对象这个词——某些语言（如 Java）根本不允许虚拟继承（即 C++ 那样的多重继承）来允许您在编译时完成此操作时间。
由于我们已经引入了多重继承（以及可怕的菱形），因此您需要留意mixins——它们是接口的有序线性链接，以解决多重继承的问题。然而，mixin 的混合效果不太好。我们最终得到了特征——是的，那些无状态的行为小斑点，你总是在C++的模板参数中看到弹出的。特征试图以优雅的方式解决行为的组合和分解问题，而不是多重继承或有序链接。
TL;DR
Detailed
Adapter adapts a given class/object to a new interface. In the case of the former, multiple inheritance is typically employed. In the latter case, the object is wrapped by a conforming adapter object and passed around.
Facade is a simple gateway to a complicated set of functionality. You make a black-box for your clients to worry less.
Proxy provides the same interface as the proxied-for class and typically does some housekeeping stuff on its own. So, instead of making multiple copies of a heavy object
Xyou make copies of a lightweight proxyPwhich in turn managesXand translates your calls as required.Decorator is used to add more gunpowder to your objects (note the term objects — you typically decorate objects dynamically at runtime). You do not hide/impair the existing interfaces of the object but.
Now that you have decorator involved, you will probably want to know why the emphasis on the word object — some languages (like Java) simply don't allow virtual inheritance (i.e. multiple inheritance as C++ does) to allow you to accomplish this at compile time.
Since we have dragged in multiple inheritances (and the dreaded diamond) you will look out for mixins — which are ordered linear chaining of interfaces to get around the problems of multiple inheritance. However, mixins don't mix that well. And we end up with traits — yes those stateless little blobs of behavior that you see pop-up all the time in template parameters in C++. Traits try to address the issues of composition and decomposition of behavior in an elegant manner while not going either for multiple inheritances or ordered chaining.
外观
例如，您可以使用外观来更轻松地调用 API。看一下这个远程外观示例。这里的想法是服务器上代码的完整实现对客户端是隐藏的。客户端调用 1 个 API 方法，该方法又可以在服务器上进行 1 个或多个 API 调用。
适配器
可以在 Wikipedia 的此处找到一个很好的示例。客户端对象
Source想要调用另一个对象Target上的方法，但另一个对象的接口与客户端期望的不同。输入适配器对象。
它可以从
Source对象进行调用，并在幕后调用应该使用的Target方法。Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() 这个调用 ---> Target.MethodWithDifferentSignatureAndName(int i)至于Proxy，我对这种设计模式没有任何经验。
Facade
You could use a facade, for example, to make calls to an API easier. Take a look at this example of a remote facade. The idea here is that the full implementation of the code on the server is hidden away from the client. The client calls 1 API method which, in turn, can make 1 or more API calls on the server.
Adapter
A good example of this can be found here, on Wikipedia. A client object
Sourcewould like to call a method on another objectTarget, but that other object's interface differs to what the client is expecting.Enter the adapter object.
It can take a call from the
Sourceobject and, behind the scenes, call theTargetmethod which should be used.Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)As for Proxy, I don't have any experience of this design pattern.