外观模式
定义
- 外观模式(Facade Pattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。外观模式又称为门面模式,它是一种对象结构型模式。
外观模式结构图
代码实现
public class SubSystemOne {
public void MethodOne(){
System.out.println("子系统方法一");
}
}
public class SubSystemTwo {
public void MethodTwo(){
System.out.println("子系统方法二");
}
}
public class SubSystemThree {
public void MethodThree(){
System.out.println("子系统方法三");
}
}
public class Facade {
SubSystemOne one;
SubSystemTwo two;
SubSystemThree three;
public Facade() {
one = new SubSystemOne();
two = new SubSystemTwo();
three = new SubSystemThree();
}
public void MethodA(){
System.out.println("方法组A()");
one.MethodOne();
two.MethodTwo();
}
public void MethodB(){
System.out.println("方法组B()");
two.MethodTwo();
three.MethodThree();
}
}
public class Client {
public static void main(String[] args) {
Facade facade = new Facade();
facade.MethodA();
facade.MethodB();
}
}
外观模式优点
- 对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式,客户代码将变得很简单,与之关联的对象也很少。
- 实现了子系统与客户之间的松耦合关系,这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。
- 降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程,因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
- 只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类。
外观模式缺点
- 不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
- 在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。
何时使用外观模式
- 在设计初期阶段,应该有意识的将不同的两个层分离;
- 在开发阶段,子系统往往因为不断的重构演化而变得越来越复杂,增加Facade可以提供一个简单的接口,减少他们之间的依赖。
- 在维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展了,为新系统开发一个外观Facade类,来提供设计粗糙或高度复杂的遗留代码的比较清晰简单接口,让新系统与Facade对象交互,Facade与遗留代码交互所有复杂工作。
往期精彩文章