外观模式的使用

6

我何时需要使用外观模式来开发应用程序?

如何区分外观模式和模板模式?

例如:在[此]文章中,我们可以看到int placeOrder(int CustomerID, List<BasketItem> Products)算法中有一些预定义的步骤。那么为什么作者不在这里使用模板模式呢?


3
"你说的将Facade和Template区分开是什么意思?Facade是一种结构型模式,而Template是一种行为型模式——我不明白你如何将两者联系起来?" - RichardOD
3个回答

9
外观模式处理接口而非实现。它的目的是将内部复杂性隐藏在一个外观简单的单一接口后面。在您提问的示例中,外观隐藏了四个类(Order、OrderLine、Address、BasketItem)在一个方法后面。
模板方法处理实现。它的目的是从几个仅以“填空”的方式不同的算法中提取公共算法。超类中的模板方法实现了公共算法,每个子类以其自己特定的方式“填空”。
那么为什么作者不在这里使用模板模式呢?
如果操作有几个相似版本,那么将placeOrder变成模板方法就有意义了。也许可以将一些方法(如placePhoneOrderplaceInternetOrderplaceManuallyEnteredOrder)重构为一个单一的模板placeOrder,其中一些子类只实现{电话、互联网、手动输入}-特定的差异。

太好了!我从中找到了我需要的东西。 - user366312

7

3
假设您有几个服务、库或其他内容。这些库需要相互操作才能执行一些更高级的服务。然后,您可能希望包装那些通常一起进行的调用和初始化代码,并提供一堆函数来隐藏这些细节并简化特定场景下使用这些服务的方法。那么,外观模式就是一个很好的应用场景。
更新:在所述文章中,PlaceOrder方法只有一个单一的实现适用于所有订单。模板模式旨在规定必须遵循的一系列步骤,但允许子类提供这些固定步骤的自定义实现。例如,如果您需要为电视订单和微波炉订单处理不同,您可以使用模板模式重新定义一些想象中的DispatchParcel方法(将微波炉作为简单包裹发送,但将电视作为额外的服务来帮助将重型设备举到楼上)。在我们的情况下,没有必要重新实现ProcessOrder步骤,因此没有必要使用模板模式,因为一个单一的实现适用于所有类型的订单。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接