使用立面图案

Question

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

如何在Facade Pattern和Template Pattern之间画线？

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

Answer 1

Facade处理接口，而不是实现。其目的是隐藏单个界面背后的内部复杂性，这在外部看起来很简单。在您的问题的示例中，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步骤，因此不需要模板模式，因为一个单独的实现适合所有类型的订单。