设计模式 - 立面答案

【问题标题】：Design Pattern - Facade设计模式 - 立面
【发布时间】：2012-11-08 11:38:08
【问题描述】：

我被要求为在线商务系统（Amazon、Play.com 等）制作一个基本的设计模式，我选择专注于外观模式，因为我觉得这种模式主要用于整个系统.这是我目前所拥有的：

系统操作：

建议的“外观模式”将由用户工作，只需查看/了解 order_product 功能，因此其他组件从这一操作“触发”。

我的问题是，对于这种类型的系统，这是一个好的和正确的设计模式吗？此外，操作，其他任何人都可以想到购买产品可能需要的任何其他操作 - 这就是我能想到的全部内容。

希望有人可以提供帮助:)

【问题讨论】：

【解决方案1】：

嗯，Facade 通常只与为大量遗留代码或库提供简单接口相关。它很少用于创建新的基础代码，除非您考虑“您的类使用库类，例如 Lists 和 Maps” 库的外观。

“外观是一个对象，它提供了一个简化的接口更大的代码体，例如类库”

对于您描述的任务，您可能会使用诸如 Mediator（在某些情况下可被视为外观）、模型/控制器/查看器、责任链（用于安全性）、Memento（用于持久性）等模式，并且可能Builder（用于以多种方式显示您的购买：HTML、PDF 发票、电子邮件...）。

【讨论】：

感谢您的回复。所以你不建议我在这里使用 Facade 模式？这似乎最有可能从我所学到的关于它们的知识中得到。我也喜欢 Bulder 模式的想法 :)
通常很难区分 Facade 和 Mediator 之间的区别。将 Facade 和 Mediator 区分开通常是一个意图和环境问题。中介者通常对公开最少方法的对象起协调作用。 Facade 通常会做同样的事情，并在更简单的 API 后面隐藏大量旧的或过于复杂的代码。因此，如果您的代码是新的并且设计良好，那么一旦您仔细观察，您认为 Facade 可能就是 Medator :)
这个答案确实很好地说明了 Mediator 和 Facade 之间的区别。 stackoverflow.com/questions/481984/facade-vs-mediator?rq=1他们的类图看起来很像，而且经常用在同层架构中，但是真的很不一样。