本篇Blog继续学习结构型模式，了解如何更优雅的布局类和对象。结构型模式描述如何将类或对象按某种布局组合以便获得更好、更灵活的结构。虽然面向对象的继承机制提供了最基本的子类扩展父类的功能，但结构型模式不仅仅简单地使用继承，而更多地通过组合与运行期的动态组合来实现更灵活的功能。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。本篇学习的是外观模式。由于学习的都是设计模式，所有系列文章都遵循如下的目录：

• 模式档案：包含模式的定义、模式的特点、解决什么问题、优缺点、使用场景等
• 模式结构：包含模式的角色定义及调用关系以及其模版代码
• 模式示例：包含模式的实现方式代码举例，生活中的简单问题映射
• 模式实践：如果工作中或开源项目用到了该模式，就将使用过程贴到这里，并且客观讨论使用的是否恰当
• 模式对比：如果模式相似，有必要体现其相似点及不同点，区分使用，说明哪些场景下使用哪种模式比较好
• 模式扩展：如果模式有与标准结构定义不同的变体形式，一并体现出其变体结构

接下来所有设计模式的介绍都暂且遵循此基本行文逻辑吗，如果某一条目没有则无需体现，但条目顺序遵循此结构

模式档案

在现实生活中，常常存在办事较复杂的例子，如办房产证或注册一家公司，有时要同多个部门联系（产权登记、契税、公证等），这时要是有一个综合部门能解决一切手续问题就好了。软件设计也是这样，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟着改变，这违背了开闭原则，也违背了迪米特法则，所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度，这就是外观模式的目标

模式定义：外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性

解决什么问题：外观模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用，客户端不需要关心各个子系统的实现细节，减少依赖。

优点：外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点：

1. 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
2. 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。

缺点：要在易用性和通用性之间找平衡，比较考验设计思路。

使用场景：通常在以下情况下考虑使用外观模式

• 解决易用性问题：外观模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口，有点类似之前讲到的迪米特法则（最少知识原则）和接口隔离原则：两个有交互的系统，只暴露有限的必要的接口。除此之外，外观模式还有点类似之前提到封装、抽象的设计思想，提供更抽象的接口，封装底层实现细节
• 解决性能问题：我们可以通过将多个接口调用替换为一个外观接口调用，减少网络通信成本，提高 App 客户端的响应速度，如果外观接口不多，我们完全可以将它跟非外观接口放到一块，也不需要特殊标记，当作普通接口来用即可。如果外观接口很多，我们可以在已有的接口之上，再重新抽象出一层，专门放置外观接口，从类、包的命名上跟原来的接口层做区分。如果外观接口特别多，并且很多都是跨多个子系统的，我们可以将外观接口放到一个新的子系统中

外观模式定义中的子系统（subsystem）也可以有多种理解方式。它既可以是一个完整的系统，也可以是更细粒度的类或者模块

模式结构

外观（Facade）模式包含以下两种主要角色。

• 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
• 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。

整体结构如下：

模式实现

依据外观模式的关系图定义两类角色代码如下：

外观角色

//外观角色
class Facade {
    private SubSystem01 obj1 = new SubSystem01();
    private SubSystem02 obj2 = new SubSystem02();
    private SubSystem03 obj3 = new SubSystem03();
    public void method() {
        obj1.method1();
        obj2.method2();
        obj3.method3();
    }
}

子系统角色

//子系统角色
class SubSystem01 {
    public void method1() {
        System.out.println("子系统01的method1()被调用！");
    }
}
//子系统角色
class SubSystem02 {
    public void method2() {
        System.out.println("子系统02的method2()被调用！");
    }
}
//子系统角色
class SubSystem03 {
    public void method3() {
        System.out.println("子系统03的method3()被调用！");
    }
}

客户端调用如下：

public class FacadePattern {
    public static void main(String[] args) {
        Facade f = new Facade();
        f.method();
    }
}

打印结果如下：

子系统01的method1()被调用！
子系统02的method2()被调用！
子系统03的method3()被调用！

模式实践

我们来看一个实践的例子：一键关机

电脑一键关机设计

电脑整机是 CPU、内存、硬盘的外观。有了外观以后，启动电脑和关闭电脑都简化了。直接 new 一个电脑。在 new 电脑的同时把 cpu、内存、硬盘都初始化好并且接好线。对外暴露方法（启动电脑，关闭电脑）。

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

而不需要自己去一个个步骤去操作。

package com.example.designpattern.facade;
public class FacadeTest {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.openComputer();
    }
}
/** * CPU类 */
class Cpu {
    public void openCpu() {
        System.out.println("启动CPU");
    }
}
/** * 内存类 */
class Ddr {
    public void openDdr() {
        System.out.println("启动内存");
    }
}
/** * 硬盘类 */
class Ssd  {
    public void openSsd() {
        System.out.println("启动硬盘");
    }
}
/** * 外观类 */
class Facade {
    private Cpu cpu;
    private Ddr ddr;
    private Ssd ssd;
    /** * 启动电脑 */
    public void openComputer() {
        this.onCPU();
        this.onDDR();
        this.onSSD();
        System.out.println("电脑启动完毕");
    }
    /** * 启动cpu */
    public void onCPU() {
        cpu = new Cpu();
        cpu.openCpu();
    }
    /** * 启动内存 */
    public void onDDR() {
        ddr = new Ddr();
        ddr.openDdr();
    }
    /** * 启动硬盘 */
    public void onSSD() {
        ssd = new Ssd();
        ssd.openSsd();
    }
}

打印结果如下：

模式对比

适配器模式和外观模式的共同点是，将不好用的接口适配成好用的接口，这里简单对比下

适配器模式和外观模式

适配器模式与外观模式的区别如下：

（a）适配器主要是为了解决接口不兼容的问题，而外观模式主要用于设计接口的易用性问题。

（b）适配器在代码结构上主要是继承加组合，外观模式在代码结构上主要是封装。

（c）适配器可以看作是事后行为，是一种“补偿模式”，主要是用来完善设计上的不足，而外观模式是在设计接口时就需要考虑的，是一种事前行为

总结一下

接口粒度设计得太大，太小都不好。太大会导致接口不可复用，太小会导致接口不易用。在实际的开发中，接口的可复用性和易用性需要权衡。针对这个问题，一个基本的处理原则是，尽量保持接口的可复用性，但针对特殊情况，允许提供冗余的外观接口，来提供更易用的接口。其实外观模式我们日常都会不经意间使用，就是分层里更上层的业务层，封装聚合了下层单一行为接口，为调用者提供一个独立且与下层接口解耦的功能。