1.外观模式
为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
一个客户类需要和多个业务类交互，由于涉及到的类比较多，导致使用时代码较为复杂。外观模式通过引入一个新的外观类(Facade)来实现该功能，该外观类的实例负责和子系统中类的实例打交道。

2.UML类图

外观模式包括两种角色：
子系统（Subsystem）：子系统是若干个类的集合，这些类的实例协同合作为用户提供所需要的功能，子系统中任何类都不包含外观类的实例引用。
外观（Facade）：外观是一个类，该类包含子系统中全部或部分类的实例引用，当用户想要和子系统中的若干个类的实例打交道时，可以代替地和子系统的外观类的实例打交道。
3.举例
作为一个android程序员，我们知道，要开发app，我们需要一台电脑、一个ide环境、一个手机。好了，上代码

public class AndroidDeveloper {
    public void tools() {
        new Computer().name();
        new Ide().name();
        new Phone().name();
    }
}

//子系统角色
class Computer {
    public void name() {
        System.out.println("Computer is Lenovo!");
    }
}

class Ide {
    public void name() {
        System.out.println("IDE is Android Studio!");
    }
}

class Phone {
    public void name() {
        System.out.println("Phone is Mi!");
    }
}

//使用模式
public class FacadeTest {
    public static void main(String[] args) {

        AndroidDeveloper developer=new AndroidDeveloper();
        developer.tools();
    }
}

4.使用场景

● 对于一个复杂的子系统，需要为用户提供一个简单的交互操作。

● 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

● 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

5.总结

外观模式优点：

● 减少客户端所需处理的对象数目，使得子系统使用起来更加容易。

● 实现了子系统与客户端之间的松耦合关系。

● 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。

外观模式缺点：

● 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。

● 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则