设计模式学习（八）-- 外观模式

外观模式（Facade）为系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

当一组接口直接面向客户端提供服务时，各系统间复杂的调用关系，会产生非常复杂而难以维护的系统，直接修改或扩展都会产生很多问题。因此引入外观模式，将这组接口进行封装，提供一个统一的外观类。

UML

通过创建Facade类，客户端只需要关心该类的具体实现即可，即使子系统实现方式发生改变，客户端也无需知晓。

举例

子系统类：

public class SubSystemOne {
    public void methodOne() {
        System.out.println("子系统方法一");
    }
}
//其他子系统方法相同，略...

外观类：

public class Facade {
    private SubSystemOne subSystemOne;
    private SubSystemTwo subSystemTwo;
    private SubSystemThree subSystemThree;
    private SubSystemFour subSystemFour;

    public Facade(){
        subSystemOne = new SubSystemOne();
        subSystemTwo = new SubSystemTwo();
        subSystemThree = new SubSystemThree();
        subSystemFour = new SubSystemFour();
    }

    public void MethodA(){
        System.out.println("方法组A");
        subSystemOne.methodOne();
        subSystemTwo.methodTwo();
        subSystemFour.methodFour();
    }

    public void MethodB(){
        System.out.println("方法组B");
        subSystemTwo.methodTwo();
        subSystemThree.methodThree();
    }
}

输出

方法组A
子系统方法一
子系统方法二
子系统方法四
方法组B
子系统方法二
子系统方法三

可以看出来外观模式相对来说比较简单，什么时候使用最好呢？
首先，在设计初期阶段，应该要有意识地将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。
其次，在开发阶段，子系统往往因为不断地重构演化而变得越来越复杂，增加外观Facade可以提供一个简单的接口，减少他们之间的依赖。
第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖于它。可以为新系统开发一个Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。