我如何知道我在应用程序开发的某个阶段需要外观模式？
如何在外观模式和模板模式之间划清界限？
例如：在[this] 的文章中，我们看到，int placeOrder(int CustomerID, List<BasketItem> Products) 在算法中有许多预定义的步骤。那么作者为什么不在这里使用模板模式呢？
【问题讨论】：
标签： language-agnostic design-patterns facade
Facade 处理接口，而不是实现。其目的是将内部复杂性隐藏在一个看似简单的单一界面后面。在您问题的示例中，外观在单个方法后面隐藏了四个类（Order、OrderLine、Address、BasketItem）。
模板方法处理实现。它的目的是从几个仅以“填空”方式不同的算法中提取通用算法。超类中的模板方法实现了通用算法，每个子类都以自己特定的方式“填空”。
那么作者为什么不在这里使用模板模式呢？
如果有多个类似的操作版本，将placeOrder 设为模板方法是有意义的。也许像placePhoneOrder、placeInternetOrder、placeManuallyEnteredOrder 这样的一些方法可以重构为单个模板placeOrder，其中一些子类仅实现{phone,internet,manual}特定的差异。
【讨论】：
假设您有一些服务、库或其他任何东西。这些库需要互操作才能执行一些更高级别的服务。然后，您可能希望包装那些通常一起使用的调用和初始化代码，并提供一堆函数来隐藏这些细节，并使这些服务在特定场景中的使用变得简单。那么它是门面模式的一个很好的用途。
更新：在文章中提到的 PlaceOrder 方法有一个适用于所有订单的单一实现。模板模式旨在规定必须遵循的一系列步骤，但允许子类提供这些固定步骤的自定义实现。例如，如果您需要以不同于处理微波炉订单的方式处理电视订单，您可以使用模板模式重新定义一些想象中的 DispatchParcel 方法（将微波炉作为一个简单的包裹发送，但电视具有额外的服务以帮助将沉重的设备提升到楼上）。在我们的例子中，不需要重新实现 ProcessOrder 步骤，因此不需要模板模式，因为一个实现适合所有类型的订单。
【讨论】：
当您有一个复杂的系统想要以简化的方式向客户端公开，或者您想要在与您的系统不兼容的现有系统上创建一个外部通信层时，外观模式是合适的。这是一个结构模式。见这里：http://en.wikipedia.org/wiki/Facade_pattern
另一方面，模板模式是一种行为模式，可以在处理组件的内部实现时为您提供帮助。见这里：http://en.wikipedia.org/wiki/Template_method_pattern
【讨论】：