概述:
在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?这就是要说的Fa?ade 模式。
为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。[GOF 《设计模式》]
结构图:
这里在附上一个有助于理解的图
未使用外观模式
使用外观模式后
外观模式在我们的开发中其实用的非常的多,随处可见,我这里就随便举个例子(可能不是很恰当,但是一看基本就懂了)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
客户端调用,男的调用方法一,女的调用方法二(好吧这个是个公厕入口)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
这样做是合理的,但是我们在调用的时候希望更简单,不需要这么多的逻辑判断,你给一个接口给我,我把参数传进去,就完事了。好,我们用外观来实现这种效果。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
|
客户端调用
1 2 3 4 5 6 7 8 9 10 11 12 |
|
使用外观模式之后,是不是感觉调用起来非常的简介。相信这个模式大家都会用!
适用性:
1.为一个复杂子系统提供一个简单接口。
2.提高子系统的独立性。
3.在层次化结构中,可以使用Facade模式定义系统中每一层的入口。
总结:
Fa?ade模式注重的是简化接口,它更多的时候是从架构的层次去看整个系统,而并非单个类的层次。
从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化
设计模式系列文章:http://www.diyibk.com/post/39.html