背景

现实生活中有这样一个例子,如你贷款买房,需要同多个机构联系。你可能需要转户口,需要去市政府去办理;需要公积金社保流水,就要去人社局打印盖章;需要薪资流水,就要去银行打印。但是,如果有一个综合部门来处理这些手续,你就不用到处跑了。

设计模式17之外观模式_java外观模式-背景

在系统开发中也是一样,如果子系统越来越多,那么访问系统的的复杂度也会变高。如果子系统发生变化,那么客户访问的逻辑也会变化,这样违背了设计中的"开闭原则"。为此我们需要外观模式,来降低系统的耦合度。

外观模式-背景2

什么是外观模式

Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.(要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。)

外观模式主要由下面3个要素组成:

  • 外观(Facade)角色:为多个子系统对外提供一个共同的接口。
  • 子系统(Sub System)角色:实现系统的部分功能,客户可以通过外观角色访问它。
  • 客户(Client)角色:通过一个外观角色访问各个子系统的功能。

要素组成关系如下:

设计模式17之外观模式_java_02结构图

代码实现

SubSystem

设计模式17之外观模式_java_03

Facade

代码测试:

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

测试结果如下:

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

关于外观模式的思考

我们为什么要使用外观模式呢?当然是为了减少系统的相互依赖,如果客户端直接访问子系统,当系统逻辑发生变化需要修改,那么客户访问的逻辑也可能需要修改。如果添加了外观模式,就只有客户与外观类之间的依赖。任你系统怎么修改。

客户不能直接访问系统,增加了系统的安全性。

但是,当系统逻辑发生变化,外观类也需要修改。所以需要考虑修改外观类的风险。