设计模式深入浅出（五）接口适配——外观

我要去旅游

大家都很喜欢去旅游，前段时间十一各地都是人山人海，于是我们想到了出国旅游。
旅游分为两种：1. 自由行 2.跟团游
1. 自由行：所有的事情都是亲力亲为，以出国游为例，我们需要自己跑到大使馆去签证，去银行兑换外币，定旅店等。虽然麻烦，但是逍遥自在。
2. 跟团游：无需你做任何事情，只要交钱，剩下的签证，旅馆预订等都有旅游社联系，搞定。方便，快捷。

程序中的“旅行社”

上面旅游的例子中，你只需要与旅行社打交道，旅行社后台将会整合访问一系列资源：大使馆，旅店，银行等，使得你的旅行顺利进行。

也可以这么说，旅行社充当了“脸”的作用，它隐藏了身后的系统：大使馆，旅店，银行等。

这样，自由行和跟团游可以示意为：

从图中可以看出，作为“你”的小人，在自由行中，有数条线引出到对应的系统中（银行，旅馆…），这可以说你与其他系统的耦合性高，同时操作复杂。

而在跟团游中，“你”只需要与旅行社打交道，剩下的系统旅馆，银行等，都被旅行社隐藏在了身后。

这里旅行社作为单一的入口点，封装了背后各系统及系统间复杂的逻辑，使得客户仅需要操作旅行社单一接口，就可以完成相应的需求。

外观模式

外观模式与跟团游，效果是一样的。

我们在编程中，因为功能的划分，我们会编写若干功能相关的子系统（大使馆，旅馆，飞机场等）。当我们要完成某些功能时，可能需要调用这些子系统，来完成我们的任务。

这就提高了客户调用代码的复杂性，同时由于直接将子系统暴露于客户，增加了耦合性。

因此我们可以将这些子系统全部“包”起来，对外部只提供一张“脸”，由“脸”负责调度背后的子系统，这些对客户来说完全是透明的。

外观模式并没有标准的UML图，只要我们理解他这种封装的思想，也就可以了。

运用外观模式会简化客户代码调用的复杂性与耦合度，但是会增加Facade内部的复杂度，因此，在封装Facade的时候，要考虑到封装的粒度。只将相关的子系统封装在Facade内部。