设计模式之——门面模式

1 门面模式的定义

门面模式：Facade Pattern，也叫做外观模式。要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。
门面模式是一种比较常用的封装模式，注重“统一的对象”，也就是提供一个访问子系统的接口，除了这个接口不允许有任何访问子系统的行为发生。
门面模式的通用类图：

门面模式通用类图

门面对象，是外界访问子系统内部的唯一途径，不管子系统内部多么杂乱无章，只要有门面对象，就可以简单访问子系统。

• Facade门面角色
  客户端可以调用门面角色的方法，门面角色知晓子系统的所有功能和职责。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就是说门面角色没有实际的业务逻辑，只是一个委托类。
• Subsystem子系统角色
  可以同时有一个或者多个子系统，每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。

2 门面模式通用示例模式

2.1 子系统通用代码

子系统是类的集合，并且每一个子系统都不相同，我们使用3个相互无关的类来代表。可以认为这3个类属于近邻，处理相关的业务，因此可以认为是一个子系统的不同逻辑处理模块，对于此子系统的访问需要通过门面进行。

1. 业务类A

@Slf4j
public class SubsystemA {

    /**
     * 业务逻辑A
     */
    public void doSomethingA() {
        log.info("{}的业务逻辑。", this.getClass().getSimpleName());
    }
}

2. 业务类B

@Slf4j
public class SubsystemB {

    /**
     * 业务逻辑B
     */
    public void doSomethingB() {
        log.info("{}的业务逻辑。", this.getClass().getSimpleName());
    }
}

3. 业务类C

@Slf4j
public class SubsystemC {

    /**
     * 业务逻辑C
     */
    public void doSomethingC() {
        log.info("{}的业务逻辑。", this.getClass().getSimpleName());
    }
}

2.2 门面对象

@Slf4j
public class Facade {
    //被委托的对象
    private SubsystemA subsystemA = new SubsystemA();
    private SubsystemB subsystemB = new SubsystemB();
    private SubsystemC subsystemC = new SubsystemC();

    /**
     * 提供给外部访问的方法
     */
    public void businessA() {
        this.subsystemA.doSomethingA();
    }

    public void businessB() {
        this.subsystemB.doSomethingB();
    }

    public void businessC() {
        this.subsystemC.doSomethingC();
    }
}

2.3 场景类

@Slf4j
public class Client {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.businessA();
        facade.businessB();
        facade.businessC();
    }
}

运行结果：

21:20:14.042 [main] INFO com.idear.design.pattern.facade.SubsystemA - SubsystemA的业务逻辑。
21:20:14.046 [main] INFO com.idear.design.pattern.facade.SubsystemB - SubsystemB的业务逻辑。
21:20:14.046 [main] INFO com.idear.design.pattern.facade.SubsystemC - SubsystemC的业务逻辑。

3 门面模式的优缺点

3.1 优点

1. 减少系统的相互依赖
   门面模式可以让场景类只需要依赖门面对象，而与子系统无关。因此可以降低系统耦合。
2. 提高灵活性
   以来减少了，不管子系统内部如何变化，只要不修改门面对象的对外接口就行，提高了灵活性。
3. 提高安全性
   外部只能通过门面访问子系统的功能，门面没有开放的就不能访问，提高了子系统的安全性。

3.2 缺点

门面模式最大的缺点是不符合开闭原则。系统投产后，一旦发现错误，九比西药修改门面角色的代码，风险比较大。

4 门面模式的使用场景

4.1 使用场景

1. 当一个复杂的系统模块或者子系统需要向外界提供一个访问接口的时候；
2. 子系统相对独立——其他(子)系统对该系统的访问只需要黑箱操作，不需要关注内部实现细节；
3. 预防低水平人员带来的风险扩散
   为降低个人代码质量对整体项目的影响风险，一般指定相关人员在特定的子系统中进行开发，然后提供门面接口进行访问操作。

4.2 注意事项

1. 一个子系统可以有多个门面
   一般情况下，一个子系统只要有一个门面就够了。但是，当以下情况可以有多个：

• 门面已经过于庞大繁杂
  代码行数太多，包含业务逻辑太多。此时可以按照职责拆分为多个门面。例如，用户信息的更新、创建、查询分别提供门面。
• 子系统可以提供不同的访问路径
  比如示例代码中，可能业务模块A需要Facade的所有模块，但是业务模块B只需要Facade的businessA()业务。此时A就可以使用Facade，而单独为业务模块B提供一个只包含businessA()业务的Facade，提高安全性。

2. 门面不参与子系统内部的业务逻辑
   以2中的代码为例，如果业务businessC()必须先调用SubsystemA.doSomethingA()，然后调用SubsystemC.doSomethingC()。这时候，可能很多时候都会按照如下进行设计：
   错误示例

    public void businessC() {
        this.subsystemA.doSomethingA();
        this.subsystemC.doSomethingC();
    }

这种设计很不靠谱，因为门面对象参与了逻辑。门面对象应该只是提供访问子系统的路径，不应该也不能参与具体的业务逻辑，否则就会产生依赖倒置的问题：子系统必须依赖门面才能被访问，同时违反了单一职责原则，破坏了系统的封装性。
那么如何解决呢？
建立一个封装类，封装完毕后提供给门面对象使用。Context封装类提供了一个联合业务joinBusinessC()，并且运行在子系统内部。Context向门面对象提供joinBusinessC()业务逻辑。
封装对象Context：

@Slf4j
public class Context {
    //被委托的对象
    private SubsystemA subsystemA = new SubsystemA();
    private SubsystemC subsystemC = new SubsystemC();

    /**
     * 联合功能
     */
    public void joinBusinessC() {
        this.subsystemA.doSomethingA();
        this.subsystemC.doSomethingC();
    }
}

门面对象：

@Slf4j
public class FacadeJoin {
    //被委托的对象
    private SubsystemA subsystemA = new SubsystemA();
    private SubsystemB subsystemB = new SubsystemB();
    private Context context = new Context();

    /**
     * 提供给外部访问的方法
     */
    public void businessA() {
        this.subsystemA.doSomethingA();
    }

    public void businessB() {
        this.subsystemB.doSomethingB();
    }

    public void businessC() {
        this.context.joinBusinessC();
    }
}

通过封装，业务只需要关注门面对象，具体的业务逻辑封装在子系统内部。即便有一天业务发生了变化，变化也会被封装在子系统内部，对于外部调用者来说，还是同一个门面，同样的方法，符合开闭原则和依赖倒置原则。

参考

1. 设计模式之禅