二 外观模式

外观模式也比较简单。

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

通过上面对外观模式的描述，很容易就想到zuul网关，通过网关的一系列调用来达到实现某个目标的需求。外观模式也是一样的。外界的调用者不用知道调用的具体细节，调用某个方法就可以。

举个栗子：

电脑是CUP、内存、硬盘的外观。有了外观以后，启动电脑和关闭电脑都简化了。

启动电脑（按一下电源键）：启动CPU、启动内存、启动硬盘

关闭电脑（按一下电源键）：关闭硬盘、关闭内存、关闭CPU

硬盘类：

public class Disk {
    public void start() {
        System.out.println("硬盘启动");
    }

    public void end() {
        System.out.println("硬盘关闭");
    }
}

Cpu类：

public class Cpu {
    public void start() {
        System.out.println("Cpu启动");
    }

    public void end() {
        System.out.println("Cpu关闭");
    }
}

内存类：

public class Memory {
    public void start() {
        System.out.println("内存启动");
    }

    public void end() {
        System.out.println("关闭内存");
    }
}

电脑类：

public class Computer {
    private Memory memory;
    private Cpu cpu;
    private Disk disk;

    public Computer() {
        memory = new Memory();
        cpu = new Cpu();
        disk = new Disk();
    }

    public void start() {
        cpu.start();
        memory.start();
        disk.start();
    }

    public void close() {
        disk.end();
        memory.end();
        cpu.end();
    }
}

当我们启动电脑的时候需要调用start方法就可以了，无需关注内部发生了什么。我们也可以为Computer建立一个接口，在外界调用的时候使用接口就可以。可能有不同的电脑启动方式不一样，那么我们只需要实现Computer的接口，重写一个实现类，这样就可以降低类之间的耦合度。

外观模式完美的体现了依赖反转(spring IOC)和迪米特法则的思想。

迪米特法则:如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

适用场景：大话设计模式的原话

    分三个阶段，首先，在设计业务初期阶段，应该有意识的将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade(也就是MVC模式),这样可以为复杂的子系统提供应该简单的接口，使得耦合大大降低。其次，在开发阶段，子系统往往因为不断重构演化而变的越来越复杂，大多数的模式使用时也会都产生很多很小的类，这本是好事，但也给外部调用它们的用户程序带来了使用上的困难，增加一个外观Facade可以提供应该简单的接口，减少它们之间的依赖。第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖它，此时用外观模式Facade也是非常合适的。你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

努力吧，皮卡丘