首页 > 代码库 > 门面模式
门面模式
门面模式的定义
门面模式(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();
}
}
通过这样一次封装后,门面对象又不参与业务逻辑了,在门面模式中,门面角色应该是
稳定,它不应该经常变化,一个系统一旦投入运行它就不应该被改变,它是一个系统对外的
接口,你变来变去还怎么保证其他模块的稳定运行呢?但是,业务逻辑是会经常变化的,我
们已经把它的变化封装在子系统内部,无论你如何变化,对外界的访问者来说,都还是同一
个门面,同样的方法——这才是架构师最希望看到的结构。
门面模式