设计模式讲解 — 外观模式（2）

解决方案

外观模式来解决

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

（1）外观模式定义

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

界面：在这里提到的界面，主要指的是从一个组件外部来看这个组件，能够看到什么，这就是这个组件的界面，也就是所说的外观。比如：你从一个类外部来看这个类，那么这个类的 public 方法就是这个类的外观，因为你从类外部来看这个类，就能看到这些。再比如：你从一个模块外部来看这个模块，那么这个模块对外的接口就是这个模块的外观，因为你就只能看到这些接口，其它的模块内部实现的东西是被接口封装隔离了的。

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

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

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

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

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

模式结构和说明

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

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

模块：接受Facade对象的委派，真正实现功能，各个模块之间可能有交互。

注意：Facade对象知道各个模块，但是各个模块不应该知道Facade对象。

使用外观模式重写示例

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

源码地址：https://gitee.com/liupeifeng3514/design_pattern

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

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

（2）其它的定义和实现都没有变化，这里就不去赘述了

（3）看看此时的客户端怎么实现，不再需要客户端去调用子系统内部的多个模块，直接使用外观对象就可以了，示例代码如下：

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

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