设计模式之外观模式

什么是外观模式

在日常编码工作中，我们都在有意无意的大量使用外观模式。只要是高层模块需要调度多个子系统（2个以上的类对象），我们都会自觉地创建一个新的类封装这些子系统，提供精简的接口，让高层模块可以更加容易地间接调用这些子系统的功能。尤其是现阶段各种第三方SDK、开源类库，很大概率都会使用外观模式。

外观模式(Facade Pattern)：外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。

结构

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

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

实现

客户调用

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

外观角色

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()被调用！");
    }
}
复制代码

优缺点：

优点：

• 减少了系统的相互依赖
• 提高了灵活性。不管系统内部如何变化，只要不影响到外观对象，任你自由活动
• 提高了安全性。想让你访问子系统的哪些业务就开通哪些逻辑，不在外观上开通的方法，你就访问不到

缺点：

• 不能很好地限制客户使用子系统类，很容易带来未知风险。
• 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

模式总结

• 外观模式十分的简单，我们只需在客户端购买和赎回即可，内部的任何操作都不需要我们关注，对于面向对象有一定基础的朋友，即使没有听说过外观模式，也完全有可能在很多时候使用它，因为它完美地体现了依赖倒转原则和迪米特法则的思想，所以是非常常用的模式之一。
• 我们使用外观模式的情况有很多，比如经典的MVC三层架构，可以考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间简历外观Facade，降低耦合。对于复杂难以维护的老系统，直接去修改或扩展都可能产生很多问题，可以分两个小组，一个开发Facade与老系统的交互，另一个只要了解Facade接口，直接开发新系统调用这些接口即可。