1 场景问题#

1.1 生活中的示例##

外观模式在现实生活中的示例很多，比如：组装电脑，通常会有两种方案。

一个方案是去电子市场把自己需要的配件都买回来，然后自己组装，绝对DIY（Do It Yourself）。这个方案好是好，但是需要对各种配件都要比较熟悉，这样才能选择最合适的配件，而且还要考虑配件之间的兼容性。如图所示：

客户完全自己组装电脑

另外一个方案，就是到电子市场，找一家专业装机的公司，把具体的要求一讲，然后就等着拿电脑就好了。当然价格会比自己全部DIY贵一些，但综合起来这还算是个不错的选择，估计也是大多数人的选择。如图所示：

找专业的装机公司组装电脑

这个专业的装机公司就相当于本章的主角——Facade。有了它，我们就不用自己去跟众多卖配件的公司打交道，只需要跟装机公司交互就可以了，由装机公司去跟各个卖配件的公司交互，并组装好电脑返回给我们。

把上面的过程抽象一下，如果把电子市场看成是一个系统，而各个卖配件的公司看成是模块的话，就类似于出现了这样一种情况：

客户端为了完成某个功能，需要去调用某个系统中的多个模块，把它们称为是A模块、B模块和C模块吧，对于客户端而言，那就需要知道A、B、C这三个模块的功能，还需要知道如何组合这多个模块提供的功能来实现自己所需要的功能，非常麻烦。

要是有一个简单的方式能让客户端去实现相同的功能多好啊，这样：

客户端就不用跟系统中的多个模块交互，而且客户端也不需要知道那么多模块的细节功能了，实现这个功能的就是Facade。

1.2 代码生成的应用##

很多公司都有这样的应用工具，能根据配置生成代码。一般这种工具都是公司内部使用，较为专有的工具，生成的多是按照公司的开发结构来实现的常见的基础功能，比如增删改查。这样每次在开发实际应用的时候，就可以以很快的速度把基本的增删改查实现出来，然后把主要的精力都放在业务功能的实现上。

当然这里不可能去实现一个这样的代码生成工具，那需要整本书的内容，这里仅用它来说明外观模式。

假设使用代码生成出来的每个模块都具有基本的三层架构，分为：表现层、逻辑层和数据层，那么代码生成工具里面就应该有相应的代码生成处理模块。

另外，代码生成工具自身还需要一个配置管理的模块，通过配置来告诉代码生成工具，每个模块究竟需要生成哪些层的代码，比如：通过配置来描述，是只需要生成表现层代码呢，还是三层都生成。具体的模块示意如图所示：

代码生成工具的模块示意图

那么现在客户端需要使用这个代码生成工具来生成需要的基础代码，该如何实现呢？

1.3 不用模式的解决方案##

有朋友会想，开发一个这样的工具或许会比较麻烦，但是使用一下，应该不难吧，直接调用不就可以了。

在示范客户端之前，先来把工具模拟示范出来，为了简单，每个模块就写一个类，而且每个类只是实现一个功能，仅仅做一个示范。

先看看描述配置的数据Model，示例代码如下：

/**
   * 示意配置描述的数据Model，真实的配置数据会很多
   */
public class ConfigModel {
      /**
       * 是否需要生成表现层，默认是true
       */
      private boolean needGenPresentation = true;
      /**
       * 是否需要生成逻辑层，默认是true
       */
      private boolean needGenBusiness = true;
      /**
       * 是否需要生成DAO，默认是true
       */
      private boolean needGenDAO = true;
      public boolean isNeedGenPresentation() {
          return needGenPresentation;
      }
      public void setNeedGenPresentation(
          this.needGenPresentation = needGenPresentation;
      }
      public boolean isNeedGenBusiness() {
          return needGenBusiness;
      }
      public void setNeedGenBusiness(boolean needGenBusiness) {
          this.needGenBusiness = needGenBusiness;
      }
      public boolean isNeedGenDAO() {
          return needGenDAO;
      }
      public void setNeedGenDAO(boolean needGenDAO) {
          this.needGenDAO = needGenDAO;
      }
}

接下来看看配置管理的实现示意，示例代码如下：

/**
   * 示意配置管理，就是负责读取配置文件，
   * 并把配置文件的内容设置到配置Model中去，是个单例
   */
public class ConfigManager {
    private static ConfigManager manager = null;
    private static ConfigModel cm = null;
    private ConfigManager(){
        //
    }
    public static ConfigManager getInstance(){
        if(manager == null){
            manager = new ConfigManager();
            cm = new ConfigModel();
            //读取配置文件，把值设置到ConfigModel中去，这里省略了
        }
        return manager;
    }
    /**
     * 获取配置的数据
     * @return 配置的数据
     */
    public ConfigModel getConfigData(){
        return cm;
    }
}

接下来就来看看各个生成代码的模块，在示意中，它们的实现类似，就是获取配置文件的内容，然后按照配置来生成相应的代码。分别看看它们的示意实现，先看生成表现层的示意实现，示例代码如下：

/**
   * 示意生成表现层的模块
   */
public class Presentation {
    public void generate(){
        //1：从配置管理里面获取相应的配置信息
        ConfigModel cm = ConfigManager.getInstance().getConfigData();
        if(cm.isNeedGenPresentation()){
            //2：按照要求去生成相应的代码，并保存成文件
            System.out.println("正在生成表现层代码文件");
        }
    }
}

/**
   * 示意生成逻辑层的模块
   */
public class Business {
    public void generate(){
        ConfigModel cm = ConfigManager.getInstance().getConfigData();
        if(cm.isNeedGenBusiness()){
            System.out.println("正在生成逻辑层代码文件");
        }
    }
}

/**
   * 示意生成数据层的模块
   */
public class DAO {
    public void generate(){
        ConfigModel cm = ConfigManager.getInstance().getConfigData();
        if(cm.isNeedGenDAO()){
            System.out.println("正在生成数据层代码文件");
        }
    }
}

此时的客户端实现，就应该自行去调用这多个模块了，示例代码如下：

public class Client {
    public static void main(String[] args) {
        //现在没有配置文件，就直接使用默认的配置，通常情况下，三层都应该生成，
        //也就是说客户端必须对这些模块都有了解，才能够正确使用它们
        new Presentation().generate();
        new Business().generate();
        new DAO().generate();
    }
}

1.4 有何问题##

仔细查看上面的实现，会发现其中有一个问题：那就是客户端为了使用生成代码的功能，需要与生成代码子系统内部的多个模块交互。

这对于客户端而言，是个麻烦，使得客户端不能简单的使用生成代码的功能。而且，如果其中的某个模块发生了变化，还可能会引起客户端也需要跟着变化。那么如何实现，才能让子系统外部的客户端在使用子系统的时候，既能简单的使用这些子系统内部的模块功能，而又不用客户端去与子系统内的多个模块交互呢？

2 解决方案#

2.1 外观模式来解决##

用来解决上述问题的一个合理的解决方案就是外观模式。那么什么是外观模式呢？

外观模式定义

外观模式定义

这里先对两个词进行一下说明，一个是界面，一个是接口。

一提到界面，估计很多朋友的第一反应就是图形界面（GUI）。其实在这里提到的界面，主要指的是从一个组件外部来看这个组件，能够看到什么，这就是这个组件的界面，也就是所说的外观。

比如：你从一个类外部来看这个类，那么这个类的public方法就是这个类的外观，因为你从类外部来看这个类，就能看到这些。

再比如：你从一个模块外部来看这个模块，那么这个模块对外的接口就是这个模块的外观，因为你就只能看到这些接口，其它的模块内部实现的东西是被接口封装隔离了的。

一提到接口，做Java的朋友的第一反应就是interface。其实在这里提到的接口，主要是指的外部和内部交互的这么一个通道，通常是指的一些方法，可以是类的方法，也可以是interface的方法。也就是说，这里说的接口，并不等价于interface，也有可能是一个类。

应用外观模式来解决的思路

仔细分析上面的问题，客户端想要操作更简单点，那就根据客户端的需要来给客户端定义一个简单的接口，然后让客户端调用这个接口，剩下的事情就不用客户端管，这样客户端就变得简单了。

当然，这里所说的接口就是客户端和被访问的系统之间的一个通道，并不一定是指Java的interface。事实上，这里所说的接口，在外观模式里面，通常指的是类，这个类被称为“外观”。

外观模式就是通过引入这么一个外观类，在这个类里面定义客户端想要的简单的方法，然后在这些方法的实现里面，由外观类再去分别调用内部的多个模块来实现功能，从而让客户端变得简单，这样一来，客户端就只需要和外观类交互就可以了。

2.2 模式结构和说明##

外观模式的结构如图所示：

外观模式结构示意图

Facade：定义子系统的多个模块对外的高层接口，通常需要调用内部多个模块，从而把客户的请求代理给适当的子系统对象。

模块：接受Facade对象的委派，真正实现功能，各个模块之间可能有交互。但是请注意，Facade对象知道各个模块，但是各个模块不应该知道Facade对象。

2.3 外观模式示例代码##

由于外观模式的结构图过于抽象，因此把它稍稍具体点，假设子系统内有三个模块，分别是AModule、BModule和CModule，它们分别有一个示意的方法，那么此时示例的整体结构如图所示：

外观模式示例代码

首先定义A模块的接口，A模块对外提供功能方法，从抽象的高度去看，可以是任意的功能方法，示例代码如下：

/**
   * A模块的接口
   */
public interface AModuleApi {
      /**
       * 示意方法，A模块对外的一个功能方法
       */
      public void testA();
}

实现A模块的接口，简单示范一下，示例代码如下：

public class AModuleImpl implements AModuleApi{
      public void testA() {
          System.out.println("现在在A模块里面操作testA方法");
      } 
}

同理定义和实现B模块、C模块，先看B模块的接口定义，示例代码如下：

public interface BModuleApi {
      public void testB();
}

public class BModuleImpl implements BModuleApi{
      public void testB() {
          System.out.println("现在在B模块里面操作testB方法");
      }
}

public interface CModuleApi {
      public void testC();
}

public class CModuleImpl implements CModuleApi{
      public void testC() {
          System.out.println("现在在C模块里面操作testC方法");
      }
}

定义外观对象，示例代码如下：

/**
   * 外观对象
   */
public class Facade {
      /**
       * 示意方法，满足客户需要的功能
       */
      public void test(){
          //在内部实现的时候，可能会调用到内部的多个模块
          AModuleApi a = new AModuleImpl();
          a.testA();
          BModuleApi b = new BModuleImpl();
          b.testB();
          CModuleApi c = new CModuleImpl();
          c.testC();
      }
}

客户端如何使用呢，直接使用外观对象就可以了，示例代码如下：

public class Client {
      public static void main(String[] args) {
          //使用Facade
          new Facade().test();
      }
}

2.4 使用外观模式重写示例##

要使用外观模式重写前面的示例，其实非常简单，只要添加一个Facade的对象，然后在里面实现客户端需要的功能就可以了。

新添加一个Facade对象，示例代码如下：

/**
   * 代码生成子系统的外观对象
   */
public class Facade {
      /**
       * 客户端需要的，一个简单的调用代码生成的功能
       */
      public void generate(){
          new Presentation().generate();
          new Business().generate();
          new DAO().generate();
      }
}

其它的定义和实现都没有变化，这里就不去赘述了
看看此时的客户端怎么实现，不再需要客户端去调用子系统内部的多个模块，直接使用外观对象就可以了，示例代码如下：

public class Client {
      public static void main(String[] args) {
          //使用Facade
          new Facade().generate();
      }
}

如同上面讲述的例子，Facade类其实相当于A、B、C模块的外观界面，Facade类也被称为A、B、C模块对外的接口，有了这个Facade类，那么客户端就不需要知道系统内部的实现细节，甚至客户端都不需要知道A、B、C模块的存在，客户端只需要跟Facade类交互就好了，从而更好的实现了客户端和子系统中A、B、C模块的解耦，让客户端更容易的使用系统。

3 模式讲解#

3.1 认识外观模式##

外观模式的目的

外观模式的目的不是给子系统添加新的功能接口，而是为了让外部减少与子系统内多个模块的交互，松散耦合，从而让外部能够更简单的使用子系统。

这点要特别注意，因为外观是当作子系统对外的接口出现的，虽然也可以在这里定义一些子系统没有的功能，但不建议这么做。外观应该是包装已有的功能，它主要负责组合已有功能来实现客户需要，而不是添加新的实现。

使用外观跟不使用相比有何变化

看到Facade的实现，可能有些朋友会说，这不就是把原来在客户端的代码搬到Facade里面了吗？没有什么大变化啊？

没错，说的很对，表面上看就是把客户端的代码搬到Facade里面了，但实质是发生了变化的，请思考：Facade到底位于何处呢？是位于客户端还是在由A、B、C模块组成的系统这边呢？

答案肯定是在系统这边，这有什么不一样吗？

当然有了，如果Facade在系统这边，那么它就相当于屏蔽了外部客户端和系统内部模块的交互，从而把A、B、C模块组合成为一个整体对外，不但方便了客户端的调用，而且封装了系统内部的细节功能，也就是说Facade与各个模块交互的过程已经是内部实现了。这样一来，如果今后调用模块的算法发生了变化，比如变化成要先调用B，然后调用A，那么只需要修改Facade的实现就可以了。

另外一个好处，Facade的功能可以被很多个客户端调用，也就是说Facade可以实现功能的共享，也就是实现复用。同样的调用代码就只用在Facade里面写一次就好了，而不用在多个调用的地方重复写。

还有一个潜在的好处，对使用Facade的人员来说，Facade大大节省了他们的学习成本，他们只需要了解Facade即可，无需再深入到子系统内部，去了解每个模块的细节，也不用和这多个模块交互，从而使得开发简单，学习也容易。

有外观，但是可以不使用

虽然有了外观，如果有需要，外部还是可以绕开Facade，直接调用某个具体模块的接口，这样就能实现兼顾组合功能和细节功能。比如在客户端就想要使用A模块的功能，那么就不需要使用Facade，可以直接调用A模块的接口。示例代码如下：

public class Client {
      public static void main(String[] args) {
          AModuleApi a = new AModuleImpl();
          a.testA();
      }
}

外观提供了缺省的功能实现

现在的系统是越做越大、越来越复杂，对软件的要求也就更高。为了提高系统的可重用性，通常会把一个大的系统分成很多个子系统，再把一个子系统分成很多更小的子系统，一直分下去，分到一个一个小的模块，这样一来，子系统的重用性会得到加强，也更容易对子系统进行定制和使用。

但是这也带来一个问题，如果用户不需要对子系统进行定制，仅仅就是想要使用它们来完成一定的功能，那么使用起来会比较麻烦，需要跟这多个模块交互。

外观对象就可以为用户提供一个简单的、缺省的实现，这个实现对大多数的用户来说都是已经足够了的。但是外观并不限制那些需要更多定制功能的用户，直接越过外观去访问内部的模块的功能。

外观模式的调用顺序示意图

外观模式的调用顺序示意图

3.2 外观模式的实现##

Facade的实现

对于一个子系统而言，外观类不需要很多，通常可以实现成为一个单例。

也可以直接把外观中的方法实现成为静态的方法，这样就可以不需要创建外观对象的实例而直接就可以调用，这种实现相当于把外观类当成一个辅助工具类实现。简要的示例代码如下：

public class Facade {
      private Facade() {
           
      }
      public static void test(){
          AModuleApi a = new AModuleImpl();
          a.testA();
          BModuleApi b = new BModuleImpl();
          b.testB();
          CModuleApi c = new CModuleImpl();
          c.testC();
      }
}

Facade可以实现成为interface

虽然Facade通常直接实现成为类，但是也可以把Facade实现成为真正的interface，只是这样会增加系统的复杂程度，因为这样会需要一个Facade的实现，还需要一个来获取Facade接口对象的工厂，此时结构如图所示：

外观实现成为接口的结构示意图

Facade实现成为interface的附带好处

如果把Facade实现成为接口，还附带一个功能，就是能够有选择性的暴露接口方法，尽量减少模块对子系统外提供的接口方法。

换句话说，一个模块的接口里面定义的方法可以分成两部分，一部分是给子系统外部使用的，一部分是子系统内部的模块间相互调用时使用的。有了Facade接口，那么用于子系统内部的接口功能就不用暴露给子系统外部了。

比如，定义如下的A、B、C模块的接口：

public interface AModuleApi {
      public void a1();
      public void a2();

      public void a3();
}

同理定义B、C模块的接口：

public interface BModuleApi {
      //对子系统外部
      public void b1();
      //子系统内部使用
      public void b2();
      //子系统内部使用
      public void b3();
}
public interface CModuleApi {
      //对子系统外部
      public void c1();
      //子系统内部使用
      public void c2();
      //子系统内部使用
      public void c3();
}

定义好了各个模块的接口，接下来定义Facade的接口：

public interface FacadeApi {
      public void a1();
      public void b1();
      public void c1();
      public void test();
}

这样定义Facade的话，外部只需要有Facade接口，就不再需要其它的接口了，这样就能有效地屏蔽内部的细节，免得客户端去调用A模块的接口时，发现了一些不需要它知道的接口，这会造成“接口污染”。

比如a2、a3方法就不需要让客户端知道，否则既暴露了内部的细节，又让客户端迷惑。对客户端来说，他可能还要去思考a2、a3方法用来干什么呢？其实a2、a3方法是对内部模块之间交互的，原本就不是对子系统外部的，所以干脆就不要让客户端知道。

Facade的方法实现

Facade的方法实现中，一般是负责把客户端的请求转发给子系统内部的各个模块进行处理，Facade的方法本身并不进行功能的处理，Facade的方法的实现只是实现一个功能的组合调用。

当然在Facade中实现一个逻辑处理也并无不可，但是不建议这样做，这不是Facade的本意，也超出了Facade的边界。

3.3 外观模式的优缺点##

松散耦合

外观模式松散了客户端与子系统的耦合关系，让子系统内部的模块能更容易扩展和维护。

简单易用

外观模式让子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟外观交互就可以了，相当于外观类为外部客户端使用子系统提供了一站式服务。

更好的划分访问层次

通过合理使用Facade，可以帮助我们更好的划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露给外部的功能集中到外观中，这样既方便客户端使用，也很好的隐藏了内部的细节。

过多的或者是不太合理的Facade也容易让人迷惑，到底是调用Facade好呢，还是直接调用模块好。

3.4 思考外观模式##

外观模式的本质

外观模式的本质：封装交互，简化调用。

Facade封装了子系统外部和子系统内多个模块的交互过程，从而简化外部的调用。通过外观，子系统为外部提供一些高层的接口，以方便它们的使用。

对设计原则的体现

外观模式很好的体现了“最少知识原则”。

如果不使用外观模式，客户端通常需要和子系统内部的多个模块交互，也就是说客户端会有很多的朋友，客户端和这些模块之间都有依赖关系，任意一个模块的变动都可能会引起客户端的变动。

使用外观模式过后，客户端只需要和外观类交互，也就是说客户端只有外观类这一个朋友，客户端就不需要去关心子系统内部模块的变动情况了，客户端只是和这个外观类有依赖关系。

这样一来，客户端不但简单，而且这个系统会更有弹性。当系统内部多个模块发生变化的时候，这个变化可以被这个外观类吸收和消化，并不需要影响到客户端，换句话说就是：可以在不影响客户端的情况下，实现系统内部的维护和扩展。

何时选用外观模式

如果你希望为一个复杂的子系统提供一个简单接口的时候，可以考虑使用外观模式，使用外观对象来实现大部分客户需要的功能，从而简化客户的使用；

如果想要让客户程序和抽象类的实现部分松散耦合，可以考虑使用外观模式，使用外观对象来将这个子系统与它的客户分离开来，从而提高子系统的独立性和可移植性；

如果构建多层结构的系统，可以考虑使用外观模式，使用外观对象作为每层的入口，这样可以简化层间调用，也可以松散层次之间的依赖关系；

3.5 相关模式##

外观模式和中介者模式

这两个模式非常类似，但是有本质的区别。

中介者模式主要用来封装多个对象之间相互的交互，多用在系统内部的多个模块之间；外观模式封装的是单向的交互，是从客户端访问系统的调用，没有从系统中来访问客户端的调用。

中介者模式的实现里面，是需要实现具体的交互功能的；而外观模式的实现里面，一般是组合调用或是转调内部实现的功能，通常外观模式本身并不实现这些功能。

中介者模式的目的主要是松散多个模块之间的耦合，把这些耦合关系全部放到中介者中去实现；而外观模式的目的是简化客户端的调用，这点和中介者模式也不同。

外观模式和单例模式

通常一个子系统只需要一个外观实例，所以外观模式可以和单例模式组合使用，把Facade类实现成为单例。当然，也可以跟前面示例的那样，把外观类的构造方法私有化，然后把提供给客户端的方法实现成为静态的。

外观模式和抽象工厂模式

外观模式的外观类通常需要和系统内部的多个模块交互，每个模块一般都有自己的接口，所以在外观类的具体实现里面，需要获取这些接口，然后组合这些接口来完成客户端的功能。

那么怎么获取这些接口呢？就可以和抽象工厂一起使用，外观类通过抽象工厂来获取所需要的接口，而抽象工厂也可以把模块内部的实现对Facade进行屏蔽，也就是说Facade也仅仅只是知道它从模块中获取的它需要的功能，模块内部的细节，Facade也不知道了。

【结构型模式七】外观模式(Facade)