门面模式

门面模式的定义

门面模式（Facade Pattern）也叫做外观模式，是一种比较常用的封装模式，其定义如

下：

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.（要求一个子系统的外部与其内部的通信必须通

过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）

门面模式注重“统一的对象”，也就是提供一个访问子系统的接口，除了这个接口不允许

有任何访问子系统的行为发生

● Facade门面角色

客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，

本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务

逻辑，只是一个委托类。

● subsystem子系统角色

可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集

合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。

子系统

public class ClassA {

public void doSomethingA(){

//业务逻辑

}

}

public class ClassB {

public void doSomethingB(){

//业务逻辑

}

}

public class ClassC {

public void doSomethingC(){

//业务逻辑

}

}

门面对象

public class Facade {

//被委托的对象

private ClassA a = new ClassA();

private ClassB b = new ClassB();

private ClassC c = new ClassC();

//提供给外部访问的方法

public void methodA(){

this.a.doSomethingA();

}

public void methodB(){

this.b.doSomethingB();

}

public void methodC(){

this.c.doSomethingC();

}

}

门面模式的优点

门面模式有如下优点。

● 减少系统的相互依赖

如果我们不使用门面模式，外界访问直接深入到子系统内部，相互之间是一种

强耦合关系，你死我就死，你活我才能活，这样的强依赖是系统设计所不能接受的，门面模

式的出现就很好地解决了该问题，所有的依赖都是对门面对象的依赖，与子系统无关。

● 提高了灵活性

依赖减少了，灵活性自然提高了。不管子系统内部如何变化，只要不影响到门面对象，

任你自由活动。

● 提高安全性

想让你访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，你休想访问

到。

门面模式的缺点

门面模式最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放

门面模式的使用场景

● 为一个复杂的模块或子系统提供一个供外界访问的接口

● 子系统相对独立——外界对子系统的访问只要黑箱操作即可

● 预防低水平人员带来的风险扩散

门面模式的注意事项

1 一个子系统可以有多个门面

● 门面已经庞大到不能忍受的程度

● 子系统可以提供不同访问路径

我们以门面模式的通用源代码为例。ClassA、ClassB、ClassC是一个子系统的中3个对

象，现在有两个不同的高层模块来访问该子系统，模块一可以完整的访问所有业务逻辑，也

就是通用代码中的Facade类，它是子系统的信任模块；而模块二属于受限访问对象，只能访

问methodB方法，那该如何处理呢？在这种情况下，就需要建立两个门面以供不同的高层模

块来访问，在原有的通用源码上增加一个新的门面即可

新增门面

public class Facade2 {

//引用原有的门面

private Facade facade = new Facade();

//对外提供唯一的访问子系统的方法

public void methodB(){

this.facade.methodB();

}

}

增加的门面非常简单，委托给了已经存在的门面对象Facade进行处理，为什么要使用委

托而不再编写一个委托到子系统的方法呢？那是因为在面向对象的编程中，尽量保持相同的

代码只编写一遍，避免以后到处修改相似代码的悲剧。

2 门面不参与子系统内的业务逻辑

我们

把门面上的methodC上的逻辑修改一下，它必须先调用ClassA的doSomethingA方法，然后再

调用ClassC的doSomethingC方法

修改门面

public class Facade {

//被委托的对象

private ClassA a = new ClassA();

private ClassB b = new ClassB();

private ClassC c = new ClassC();

//提供给外部访问的方法

public void methodA(){

this.a.doSomethingA();

}

public void methodB(){

this.b.doSomethingB();

}

public void methodC(){

this.a.doSomethingA();

this.c.doSomethingC();

}

}

这样设计是非常不靠谱的，为什么呢？因为你已经让门面对象参与了业务逻辑，门

面对象只是提供一个访问子系统的一个路径而已，它不应该也不能参与具体的业务逻辑，否

则就会产生一个倒依赖的问题：子系统必须依赖门面才能被访问，这是设计上一个严重错

误，不仅违反了单一职责原则，同时也破坏了系统的封装性。

说了这么多，那对于这种情况该怎么处理呢？建立一个封装类，封装完毕后提供给门面

封装类

public class Context {

//委托处理

private ClassA a = new ClassA();

private ClassC c = new ClassC();

//复杂的计算

public void complexMethod(){

this.a.doSomethingA();

this.c.doSomethingC();

}

}

该封装类的作用就是产生一个业务规则complexMethod，并且它的生存环境是在子系统

内，仅仅依赖两个相关的对象，门面对象通过对它的访问完成一个复杂的业务逻辑

门面类

public class Facade {

//被委托的对象

private ClassA a = new ClassA();

private ClassB b = new ClassB();

private Context context = new Context();

//提供给外部访问的方法

public void methodA(){

this.a.doSomethingA();

}

public void methodB(){

this.b.doSomethingB();

}

public void methodC(){

this.context.complexMethod();

}

}

通过这样一次封装后，门面对象又不参与业务逻辑了，在门面模式中，门面角色应该是

稳定，它不应该经常变化，一个系统一旦投入运行它就不应该被改变，它是一个系统对外的

接口，你变来变去还怎么保证其他模块的稳定运行呢？但是，业务逻辑是会经常变化的，我

们已经把它的变化封装在子系统内部，无论你如何变化，对外界的访问者来说，都还是同一

个门面，同样的方法——这才是架构师最希望看到的结构。