常用设计模式有23中,分为:
创建型模式(主要用于创建对象)
1、单例模式 2、工厂方法模式 3、抽象工厂模式 4、建造者模式 5、原型模式行为型模式 (主要用于描述对象或类是怎样交互和怎样分配职责)
1、模板方法模式 2、中介者模式 3、命令模式 4、责任链模式 5、策略模式 6、迭代器模式
7、观察者模式 8、备忘录模式 9、访问者模式 10、状态模式 11、解释器模式结构型模式(主要用于处理类或对象的组合)
1、代理模式 2、装饰模式 3、适配器模式 4、组合模式 5、外观模式(门面模式) 6、享元模式 7、桥梁模式
外观模式(
门面模式
)
门面模式(Facade Pattern)也叫做外观模式,是一种比较常用的封装模式,其定义如下:
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。
门面模式注重“统一的对象”,也就是提供一个访问子系统的接口,除了这个接口不允许有任何访问子系统的行为发生
Subsystem Classes是子系统所有类的简称,它可能代表一个类,也可能代表几十个对象的集合,我们把这些对象全部圈入子系统的范畴
门面模式的角色
● Facade门面角色
客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去,也就说该角色没有实际的业务逻辑,只是一个委托类。
● subsystem子系统角色
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。子系统并不知道门面的存在。对于子系统而言,门面仅仅是另外一个客户端而已。
门面模式的通用源码
先来看子系统源代码。由于子系统是类的集合,因此要描述该集合很花费精力,每一个子系统都不相同,我们使用3个相互无关的类来代表,如代码清单23-8所示。
<span style="font-size:18px;">代码清单23-8 子系统
public class ClassA {
public void doSomethingA(){
//业务逻辑
}
}
public class ClassB {
public void doSomethingB(){
//业务逻辑
}
}
public class ClassC {
public void doSomethingC(){
//业务逻辑
}
}</span>
这3个类属于近邻,处理相关的业务,因此应该被认为是一个子系统的不同逻
辑处理模块,
对于此子系统的访问需要通过门面进行,如代码清单23-9所示。
<span style="font-size:18px;">代码清单23-9 门面对象
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();
}
} </span>
业务逻辑改变时,不改变子系统对外暴露的接口、方法,只改变内部的处理逻辑
门面模式的优点
● 减少系统的相互依赖
● 提高了灵活性
● 提高安全性
门面模式的缺点
门面模式最大的缺点就是不符合开闭原则,
这就需要大家在设计的时候慎之又慎,多思考几遍才会有好收获。
使用场景
● 为一个复杂的模块或子系统提供一个供外界访问的接口
● 子系统相对独立——外界对子系统的访问只要黑箱操作即可
● 预防低水平人员带来的风险扩散
注意事项
1)一个子系统可以有多个门面
子系统可以提供不同访问路径
2)门面不参与子系统内的业务逻辑
门面 它不应该也不能参与与子系统内的业务逻辑
否则就会产生一个倒依赖的问题:子系统必须依赖门面才能被访问,这是设计上一个严重错误,不仅违反了单一职责原则,同时也破坏了系统的封装性。
在门面模式中,门面角色应该是稳定,它不应该经常变化,一个系统一旦投入运行它就不应该被改变