【1】基本概念
外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
【2】简单分析
我们先来看下该设计模式的UML结构图:
【3】如何用java语言实现该设计模式:
由于该设计模式比较简单,而且我们平时在开发项目的过程中经常会用到该设计模式的,我就不做过多的解析了,针对上面的UML结构图分别贴出各个类的代码:
3.1 源码:
package ;
public class SubSystemOne {
public void methodOne(){
("子系统方法一");
}
}
其实, , ,的源码和 的源码类似,只是方法内部输出的内容不同,在这里本人就省略列出其它子系统类的源码了。呵呵
3.2 类源码:
package ;
public class Facade {
SubSystemOne subOne;
SubSystemTwo subTwo;
SubSystemThree subThree;
SubSystemFour subFour;
public Facade(){
subOne = new SubSystemOne();
subTwo = new SubSystemTwo();
subThree = new SubSystemThree();
subFour = new SubSystemFour();
}
public void invokeMethodA(){
("-------方法组A--------");
();
();
();
}
public void invokeMethodB(){
("-------方法组B--------");
();
();
();
}
}
3.3 类源码:
package ;
public class FacadeClient {
public static void main(String[] args) {
Facade facade = new Facade();
//调用组件A
();
//调用组件B
();
}
}
【4】何时使用外观模式
4.1 在设计初期阶段,应该要有意识的将不同的两个层分离,比如经典的三层构架,就需要考虑在数据访问层和业务逻辑层,业务逻辑层和表示层的层与层之间建立外观Facade,这样可以为复杂的子系统提供一个简单的接口,使得耦合大大降低。
4.2 在开发阶段,子系统往往因为不断的重构演化而变得越来越复杂,大多数的模式使用时也都会产生很多很小的类,这本是好事,但也给外部调用它们的用户程序带来了使用上的困难,增加外观Facade可以提供一个简单的接口,减少它们之间的依赖。
4.3 在维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展了,但因为它包含非常重要的功能,新的需求开发必须依赖于它。此时用外观模式Facade也是非常合适的。例如可以开发一个外观Facade类,来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,让新系统与Facade对象交互,Facade与遗留代码交互所有复杂的工作。
至此,我们应该对外观模式有了解和何时使用该模式了吧,希望大家多多采用设计模式提高我们代码的质量和提高维护性和扩展性。
本文为 原创,欢迎大家继续关注Me的博文,欢迎大家转载,谢谢!