设计模式深入浅出(五)接口适配——外观
我要去旅游
大家都很喜欢去旅游,前段时间十一各地都是人山人海,于是我们想到了出国旅游。
旅游分为两种:1. *行 2.跟团游
1. *行:所有的事情都是亲力亲为,以出国游为例,我们需要自己跑到大使馆去签证,去银行兑换外币,定旅店等。虽然麻烦,但是逍遥自在。
2. 跟团游:无需你做任何事情,只要交钱,剩下的签证,旅馆预订等都有旅游社联系,搞定。方便,快捷。
程序中的“旅行社”
上面旅游的例子中,你只需要与旅行社打交道,旅行社后台将会整合访问一系列资源:大使馆,旅店,银行等,使得你的旅行顺利进行。
也可以这么说,旅行社充当了“脸”的作用,它隐藏了身后的系统:大使馆,旅店,银行等。
这样,*行和跟团游可以示意为:
从图中可以看出,作为“你”的小人,在*行中,有数条线引出到对应的系统中(银行,旅馆…),这可以说你与其他系统的耦合性高,同时操作复杂。
而在跟团游中,“你”只需要与旅行社打交道,剩下的系统旅馆,银行等,都被旅行社隐藏在了身后。
这里旅行社作为单一的入口点,封装了背后各系统及系统间复杂的逻辑,使得客户仅需要操作旅行社单一接口,就可以完成相应的需求。
外观模式
外观模式与跟团游,效果是一样的。
我们在编程中,因为功能的划分,我们会编写若干功能相关的子系统(大使馆,旅馆,飞机场等)。当我们要完成某些功能时,可能需要调用这些子系统,来完成我们的任务。
这就提高了客户调用代码的复杂性,同时由于直接将子系统暴露于客户,增加了耦合性。
因此我们可以将这些子系统全部“包”起来,对外部只提供一张“脸”,由“脸”负责调度背后的子系统,这些对客户来说完全是透明的。
外观模式并没有标准的UML图,只要我们理解他这种封装的思想,也就可以了。
运用外观模式会简化客户代码调用的复杂性与耦合度,但是会增加Facade内部的复杂度,因此,在封装Facade的时候,要考虑到封装的粒度。只将相关的子系统封装在Facade内部。