外观模式的使用
我如何知道在应用程序开发的某个时刻我需要一个外观模式？
如何区分外观模式和模板模式？
例如：在[this]文章中，我们看到，int placeOrder(int CustomerID, List 算法中有许多预定义步骤。那么作者为什么不在这里使用Template Pattern呢？
How can I know that I need a facade Pattern at a point in my application development?
How can I draw the line between Facade Pattern and Template Pattern?
For example: In [this] article, we see that, int placeOrder(int CustomerID, List<BasketItem> Products) has a number of predefined steps in the algorithm. So why don't the author use Template Pattern here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
外观处理的是接口，而不是实现。其目的是将内部复杂性隐藏在看似简单的单一界面后面。在您问题的示例中，外观在单个方法后面隐藏了四个类（Order、OrderLine、Address、BasketItem）。
模板方法涉及实现。其目的是从几种仅以“填空”方式不同的算法中提取通用算法。超类中的模板方法实现通用算法，每个子类以自己特定的方式“填补空白”。
如果存在多个类似的操作版本，则将
placeOrder设为模板方法是有意义的。也许一些方法，例如placePhoneOrder、placeInternetOrder、placeManuallyEnteredOrder可以重构为单个模板placeOrder，并通过一些子类实现只有{phone,internet,manual}特定的差异。Facade deals with interface, not implementation. Its purpose is to hide internal complexity behind a single interface that appears simple on the outside. In the example from your question, the facade hides four classes (Order, OrderLine, Address, BasketItem) behind a single method.
Template method deals with implementation. Its purpose is to extract the common algorithm from several ones that differ only in a 'fill in the blanks' way. The template method in the superclass implements the common algorithm and each subclass 'fills in the blanks' in its own specific way.
It would make sense to make
placeOrdera template method if there were several similar versions of the operation. Maybe a few methods likeplacePhoneOrder,placeInternetOrder,placeManuallyEnteredOrdercould be refactored into a single templateplaceOrderwith some subclasses implementing only the {phone,internet,manual}-specific differences.当您有一个复杂的系统，您希望以简化的方式向客户端公开，或者您希望在与您的系统不兼容的现有系统上创建外部通信层时，外观模式是合适的。这是一种结构模式。请参阅此处：http://en.wikipedia.org/wiki/Facade_pattern
模板模式，位于另一方面，是一种行为模式，它将在处理组件的内部实现时为您提供帮助。请参阅此处：http://en.wikipedia.org/wiki/Template_method_pattern
The facade pattern is appropriate when you have a complex system that you want to expose to clients in a simplified way, or you want to make an external communication layer over an existing system which is incompatible with your system. It is a structural pattern. See here: http://en.wikipedia.org/wiki/Facade_pattern
The template pattern, on the other hand, is a behavioral pattern that will help you when dealing with the inner implementation of a component. See here: http://en.wikipedia.org/wiki/Template_method_pattern
假设您有一些服务、图书馆或其他什么。这些库需要互操作才能执行一些更高级别的服务。然后，您可能希望包装那些通常一起使用的调用和初始化代码，并提供一堆函数来隐藏这些细节，并使在特定场景中使用这些服务变得简单。那么门面图案就很好用了。
更新：在文章中提到 PlaceOrder 方法有一个适用于所有订单的实现。模板模式旨在规定一系列必须遵循的步骤，但允许子类提供这些固定步骤的自定义实现。例如，如果您需要以不同于微波炉订单的方式处理电视订单，您可以使用模板模式重新定义一些想象中的 DispatchParcel 方法（将微波炉作为简单的包裹发送，但电视提供额外的服务，以帮助将重型设备提升到目的地）上层）。在我们的例子中，不需要重新实现 ProcessOrder 步骤，因此不需要模板模式，因为一种实现适合所有类型的订单。
Suppose you have a few services, libraries or whatever. These libraries need interoperation in order to perform some higher level services. Then you may wish to wrap those calls and intialization code that usually go together and offer a bunch of functions to hide those details and make it simple to use those services for specific scenarios. Then it is a good use for facade pattern.
UPDATE: In the article mentioned the PlaceOrder method has one single implementation that works for all orders. Template pattern is meant to prescribe a series of steps that have to be followed but allow subclasses to offer their custom implementation of those fixed steps. For example, if you needed orders for televisions to be processed differently from orders for microwaves you could use the template pattern to redefine some imaginary DispatchParcel method (to send microwave as a simple package but television with extra service to help lift the heavy device to the upper floor). In our case there is no need for reimplementation of ProcessOrder steps so there is no need for template pattern as one single implementation suits all types of orders.