Facade pattern在如今的架构中扮演重要的角色。把Facade pattern看作是提供模块间互动的API接口，其背后隐藏着复杂的代码逻辑，让开发者不用去理会其内部的运行。只要API接口不变，你可以再你的模块内随意改用任何的框架，而不需要大心会影响到系统其他的部分。

　　下方是一个很简单的例子，我们的模块有几个私有的函数，另外提供一个facade让外界来访问。

　　下一段我们将介绍mediator pattern。Facade pattern 和Mediator pattern 的差别在Facade pattern 用来暴露已存在的函数，而Mediator pattern 则可以增加函数。

　　The Mediator Pattern

　　机场塔台控制中心是mediator pattern 最好的比喻。塔台决定哪架飞机可以升空或降落，所有的消息通讯都必须通过塔台，而不是飞机间自己决定。在一个系统内，模块之间直接互相交换消息，如果模块数量太多，就显得难以维护，这时引入mediator是绝佳时机。Mediator也像个中介，让模块间免于显示地互相调用，来达到解耦的目的。如果你曾应用过Observer pattern来实现事件广播机制，你就会发现mediator相对简单。

　　让我们来看看模块如何与mediator互动的。

　　把模块当成publisher，把mediator当作publisher和subscriber。模块1广播一个事件去通知mediator做事，mediator收到消息后通知模块2来完成模块1交代的事情，模块2完成工作后再回去通知mediator，在这同时，模块3页收到mediator的要求纪录日志。没有任何模块可以直接互相通讯。如果模块3中途执行失败或中间，mediator可以重启模块3然后继续完成任务，这样的解耦处理可以保证其他模块运行正常。

　　Mediator的优势

　　通过引入接口的概念，解放模块之间的耦合，让模块可以广播或接收信息而不需要系统其他部分的运行，可以很容易增加或移除功能。

　　mediator的弊端

　　模块间是间接沟通，所以会稍微降低性能。而且因为是广播与接收的机制，会增加排查问题的难度。

　　下面是个例子：

　　以下是一个实际案例：

　　相关资料

Stoyan Stefanov — Page 168, Java Patterns

HB Stone — Java Design Patterns: Mediator

Vince Huston — The Mediator Pattern (not specific to Java, but a concise)

　　实际应用Facade

　　我们把Facade当作一个抽象层放在mediator和模块之间，所有的模块只需要注意到Facade抽象层。这抽象层负责提供一致性的接口供模块访问，模块必须通过Facade才能与mediator通讯。

　　此外，facade也扮演着安全卫士的作用，检查模块的访问权限。比如有个模块广播：“dataValidationCompletedWriteToDB”事件，这时候facade就会检查模块是否有对资料进行写入的权限，这么做是为了避免不必要的操作。

　　实际应用Mediator

　　Mediator在我们的架构中很重要，我们已经简单的讨论过它，再次在深入些。

　　Mediator的主要职责在管理模块的生命周期，当它收到消息时，它必须决定如何响应，这牵扯到是否启动或停止某个模块。当模块一旦启动，它应该自动完成任务，而什么情况下，模块需要呗停止呢？如果Mediator监听到特定的模块发生异常，要有机制可以让模块重新启动然后继续去完成未完的工作，这么做是为了降低用户的反感。

　　另外，从性能方面考虑，Mediator可以动态增加或删除模块，通常应用在当初始页面没有某个特定功能时，但需要在用户需要动态能加载进来时。

　　异常管理也可以由Mediator来处理，模块出了广播业务逻辑需要的信息外，也可以广播异常的消息让Mediator来决定接下来的任务，例如停止或调用模块。这种中心式的异常管理，让逻辑处理归于一处，不散落在各模块里，便以维护。

　　最后，把所有东西这在一起

　　模块代表应用程序的一块块功能，他们负责发布消息通知程序，而且可以耦合一些操作DOM的工具，但最好不要依赖于系统内其他的模块。另外模块并不关心：

哪些组件或模块的订阅

执行的环境

　　Facade 是一层抽象层，避免让模块与核心直接接触。它也负责模块处理权限的开关。

　　Mediator(核心)是消息订阅/发布的管理者，它负责管理，启动和调用模块，适用于加载动态模块。