最佳使用设计模式：适配器或外观
我无法决定哪种模式最适合以下问题。
我有一个客户端系统，它将与一个单独的子系统交互。该子系统非常复杂，因此我需要两者之间的接口来简化客户端系统。这听起来非常适合外观模式，但我认为适配器模式也适合我的问题。
如果中间的接口通过简单的 API 调用来调用子系统上的各个任务，会有什么区别吗？
I can't decide on which pattern is best suited to the following problem.
I have a client system who will be interacting with a separate subsystem. The subsystem is quite complicated and so I need an interface between the two to simplify the client system. This sounds like a perfect fit for Facade pattern but I think Adapter pattern too fits for my problem.
Does it make any difference if the interface in the middle calls individual tasks on the subsystem through simple API calls?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
从你的描述来看，它更符合外观的公认定义，但我想说它更多的是语义辩论。一般来说，外观更多地降低了与整个子系统接口的复杂性，而适配器更适合调整现有接口或调用您的特定需求（例如，基本功能已存在，但返回类型并不完全是您想要的， ETC）。
From your description its more in-line with the accepted definition of the Facade, but I'd say its more of a semantic debate than anything else. Facade in general is more reducing the complexity of interfacing with an entire subsystem, whereas adapter is more geared towards tweaking an existing interface or call to your specific needs (eg the basic functionality is there but the return types aren't quite what you want, etc).
当您想要将现有类的接口调整为客户端期望使用的另一个接口时，可以使用适配器模式。它通常只涉及从一个接口的方法到另一个接口的相应方法的委托或转换。
当您想要通过公开客户端可以使用的一组更简单的 API 来简化复杂的系统时，可以使用外观。它涉及将复杂的 API 调用模式转换为单个 API 调用。
你的情况听起来更像是你需要一个外观而不是一个适配器。仅实现适配器模式不会给您带来 API 简化的好处。最后，你怎么称呼它并不重要。而且这些模式并不是排他性的。您可以以给您带来最大利益的方式混合两者。
Adapter pattern is used when you want to adapt an existing class's interface to another interface that a client expects to work with. It usually just involves delegation or translation from a method of one interface to the corresponding method of the other.
Facade is used when you want to simplify a complex system by exposing a simpler set of APIs that a client can work with. It involves translating a complex pattern of API calls into a single API call.
Your case sounds more like you need a facade than an adapter. Implementing just the adapter pattern will not give you the benefit of API simplification. In the end, it doesn't matter what you call it. And these patterns are not exclusive. You could mix both in a way that gives you the most benefit.
这显然似乎是一个外观模式案例，您的目标是简化而不是实际的适应。
立面定义：
适配器定义：
定义摘自：http://dofactory.com/Patterns/Patterns.aspx
This clearly seems to be a Facade pattern case your goal is simplification rather than an actual adaptation.
Façade Definition:
Adapter Definition:
Definitions lifted from: http://dofactory.com/Patterns/Patterns.aspx
Facade 和 Adapter 之间的区别主要在于意图。
如果您想做的是简化界面，那么您正在寻找外观。如果你想调整接口以便它可以用作其他东西，那么它就是一个适配器。
但说实话，你怎么称呼它，问题是什么？我的经验法则是，如果您正在实现现有接口，您可能正在使用适配器接口。如果您正在创建一个新的简化界面，那么它就是一个外观。
The difference between Facade and Adapter is mostly the intent.
If what you want to do is simplify the interface then you are looking at a Facade. If you want to Adapt the interface so that it can be used as something else then its an Adapter.
But really, what is the problem how you call it? My rule of thumb is if you are implementing an existing interface you probably are using the Adapter interface. If you are creating a new simplified interface its a Facade.
外观模式（为更大的代码体提供简化接口的对象< /em>) 适合您的用例。
使用外观的清单：（来自链接的维基百科文章）
有关 Facade 的更多详细信息，请参阅相关 SE 问题。
什么是外观设计模式？
尽管外观< /em> 和 Adapter 是结构模式，意图不同（ samitgaur 答案很好地解释了意图部分）。
由于您没有将一个接口转换为另一接口，因此适配器无法满足您的目的。
相关SE问题：
有什么区别外观和适配器模式之间？
Facade pattern (An object that provides a simplified interface to a larger body of code) fits for your use case.
Checklist to use Facade: ( From linked Wikipedia article)
Related SE question for more details on Facade.
What is Facade Design Pattern?
Even though both Facade and Adapter are structural patterns, the intent is different( samitgaur answer explained the intent part nicely).
Since you are not converting one interface to other interface, Adapter does not serve your purpose.
Related SE question:
What is the difference between the Facade and Adapter Pattern?
外观处理的是接口，而不是实现。其目的是将内部复杂性隐藏在看似简单的单一界面后面。
Facade deals with interface, not implementation. Its purpose is to hide internal complexity behind a single interface that appears simple on the outside.