language-agnostic - 立面图案的使用

Question

我怎么知道在我的应用程序开发中我需要一个外观模式？

如何在外观图案和模板图案之间划清界限？

例如：在[this]文章中，我们看到，int placeOrder(int CustomerID, List<BasketItem> Products)算法中有许多预定义的步骤。那么作者为什么不在这里使用模板模式呢？

Answer 1

Facade 处理接口，而不是实现。其目的是将内部复杂性隐藏在一个看似简单的单一界面后面。在您问题的示例中，外观在单个方法后面隐藏了四个类（Order、OrderLine、Address、BasketItem）。

模板方法处理实现。它的目的是从几个仅以“填空”方式不同的算法中提取通用算法。超类中的模板方法实现了通用算法，每个子类都以自己特定的方式“填空”。

那么作者为什么不在这里使用模板模式呢？

placeOrder如果有几个类似的操作版本，那么制作一个模板方法是有意义的。也许像placePhoneOrder, placeInternetOrder,之类的一些方法placeManuallyEnteredOrder可以重构为单个模板placeOrder，其中一些子类仅实现 {phone,internet,manual} 特定的差异。

Answer 2

当您有一个复杂的系统想要以简化的方式向客户端公开，或者您想要在与您的系统不兼容的现有系统上创建一个外部通信层时，外观模式是合适的。它是一种结构模式。见这里：http ://en.wikipedia.org/wiki/Facade_pattern

另一方面，模板模式是一种行为模式，可以帮助您处理组件的内部实现。见这里：http ://en.wikipedia.org/wiki/Template_method_pattern

Answer 3

假设您有一些服务、库或其他任何东西。这些库需要互操作才能执行一些更高级别的服务。然后，您可能希望包装那些通常一起使用的调用和初始化代码，并提供一堆函数来隐藏这些细节，并使这些服务在特定场景中的使用变得简单。然后它是外观模式的一个很好的用途。

更新：在文章中提到 PlaceOrder 方法有一个适用于所有订单的单一实现。模板模式旨在规定必须遵循的一系列步骤，但允许子类提供这些固定步骤的自定义实现。例如，如果您需要以不同于处理微波炉订单的方式处理电视订单，您可以使用模板模式重新定义一些想象中的 DispatchParcel 方法（将微波炉作为一个简单的包裹发送，但电视具有额外的服务以帮助将沉重的设备提升到楼上）。在我们的例子中，不需要重新实现 ProcessOrder 步骤，因此不需要模板模式，因为一个单独的实现适合所有类型的订单。