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

对于面向对象有一定基础的朋友，即使没有听说过外观模式，也完全有可能在很多时候使用它，因为它完美的体现了依赖倒转原则和迪米特法则的思想，所以是非常有用的设计模式之一。

外观模式需要一个外观类，它需要了解所有的子系统的方法或属性，进行组合，以备外界调用。

外观类，知道哪些子系统负责处理请求，将客户端的请求代理给适当的子系统对象：

public class Facade {
    private SubSystemOne one;
    private SubSystemTwo two;
    private SubSystemThree three;

    public Facade() {
        one = new SubSystemOne();
        two = new SubSystemTwo();
        three = new SubSystemThree();
    }

    public void methodA(){
        System.out.println("方法组A");
        one.methodOne();
        two.methodTwo();
        three.methodThree();
    }

    public void methodB(){
        System.out.println("方法组B");
        one.methodOne();
        three.methodThree();
    }
}

子系统一：

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 FacadeTest {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.methodA();
        facade.methodB();
    }
}

输出结果：

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

以上就是外观模式的组成，那么外观模式什么时候用最好呢？

什么时候用：

这要分三个阶段来说

1. 在设计初期阶段，应该要有意识地将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合度大大降低。

2. 在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数的模式使用时也都会产生很多很小的类，这本是好事，但也给外部调用它们的用户程序带来了使用上的困难，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。

3. 在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖于它。此时使用外观模式Facade也是非常合适的。你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

对于复杂难以维护的老系统，直接去改或去扩展都可能产生很多问题，分两个小组，一个开发Facade与老系统的交互，另一个只要了解Facade的接口，直接开发新系统调用这些接口即可，可以减少很多不必要的麻烦。