结构型模式 ————顺口溜:适装桥组享代外
目录
1、门面模式(外观模式)
外观模式(Facade Pattern)隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口。它向现有的系统添加一个接口,来隐藏系统的复杂性。这种模式涉及到一个单一的类,该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
- 意图:为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
- 主要解决:降低访问复杂系统的内部子系统时的复杂度,简化客户端与之的接口。
- 何时使用: 1、客户端不需要知道系统内部的复杂联系,整个系统只需提供一个"接待员"即可。 2、定义系统的入口。
- 如何解决:客户端不与系统耦合,外观类与系统耦合。
- 关键代码:在客户端和复杂系统之间再加一层,这一层将调用顺序、依赖关系等处理好。
- 应用实例: 1、去医院看病,可能要去挂号、门诊、划价、取药,让患者或患者家属觉得很复杂,如果有提供接待人员,只让接待人员来处理,就很方便。 2、JAVA 的三层开发模式。
1.1 门面模式UML类图
1.2 日常生活看门面模式
- 大话设计模式中的例子,散户不直接购买股票,购买基金,交由基金经理来决定,基金经理就是一个门面模式。
- 我有钱了我想自己盖一套小洋楼,门面模式如下图:
1.3 使用场景
- 为复杂的模块或子系统提供外界访问的模块。
- 子系统相对独立。
- 预防低水平人员带来的风险。
1.4 Java代码实现
使用门面模式还有一个附带的好处,就是能够有选择性地暴露方法。一个模块中定义的方法可以分成两部分,一部分是给子系统外部使用的,一部分是子系统内部模块之间相互调用时使用的。有了Facade类,那么用于子系统内部模块之间相互调用的方法就不用暴露给子系统外部了。
比如,定义如下A、B、C模块。
public class Module {
/**
* 提供给子系统外部使用的方法
*/
public void a1(){};
/**
* 子系统内部模块之间相互调用时使用的方法
*/
public void a2(){};
public void a3(){};
}
public class ModuleB {
/**
* 提供给子系统外部使用的方法
*/
public void b1(){};
/**
* 子系统内部模块之间相互调用时使用的方法
*/
public void b2(){};
public void b3(){};
}
public class ModuleC {
/**
* 提供给子系统外部使用的方法
*/
public void c1(){};
/**
* 子系统内部模块之间相互调用时使用的方法
*/
public void c2(){};
public void c3(){};
}
public class ModuleFacade {
ModuleA a = new ModuleA();
ModuleB b = new ModuleB();
ModuleC c = new ModuleC();
/**
* 下面这些是A、B、C模块对子系统外部提供的方法
*/
public void a1(){
a.a1();
}
public void b1(){
b.b1();
}
public void c1(){
c.c1();
}
}
这样定义一个ModuleFacade类可以有效地屏蔽内部的细节,免得客户端去调用Module类时,发现一些不需要它知道的方法。比如a2()和a3()方法就不需要让客户端知道,否则既暴露了内部的细节,又让客户端迷惑。对客户端来说,他可能还要去思考a2()、a3()方法用来干什么呢?其实a2()和a3()方法是内部模块之间交互的,原本就不是对子系统外部的,所以干脆就不要让客户端知道。
2、门面模式在源码中应用
2.1 MyBatis源码中门面模式体现
外观模式,主要理解外观。通俗一点可以认为这个模式是将子系统封装到一起,提供给应用的层面就提供一个方法。不直接由应用层直接访问子系统。
下面我们看看ibatis的源码来具体理解外观模式。
public MetaObject newMetaObject(Object object) {
return MetaObject.forObject(object, this.objectFactory, this.objectWrapperFactory, this.reflectorFactory);
}
上述代码其实是完成一个创建MetaObject的事情,但是它是将一个负责创建MetaObject的子系统放在了这个方法里面。为什么要这么做?实际上如果直接让我们应用层去使用MetaObject.forObject(object,this.objectFactory,this.objectWrapperFactory,this.reflectorFactory);这个方法。可以看出参数实在太多,而Configuration类使用外观模式,外观类并不具体实现什么,他只是负责调用和管理子系统
下面看看configuration中的构造器
可以把上面的objectFactory,objectWrapperFactory,reflectorFactory看作三个子系统
接下来到MetaObject的里面看看forObject方法
public static MetaObject forObject(Object object, ObjectFactory objectFactory, ObjectWrapperFactory objectWrapperFactory, ReflectorFactory reflectorFactory) {
return object == null ? SystemMetaObject.NULL_META_OBJECT : new MetaObject(object, objectFactory, objectWrapperFactory, reflectorFactory);
}
对应的构造函数
private MetaObject(Object object, ObjectFactory objectFactory, ObjectWrapperFactory objectWrapperFactory, ReflectorFactory reflectorFactory) {
this.originalObject = object;
this.objectFactory = objectFactory;
this.objectWrapperFactory = objectWrapperFactory;
this.reflectorFactory = reflectorFactory;
if (object instanceof ObjectWrapper) {
this.objectWrapper = (ObjectWrapper)object;
} else if (objectWrapperFactory.hasWrapperFor(object)) {
this.objectWrapper = objectWrapperFactory.getWrapperFor(this, object);
} else if (object instanceof Map) {
this.objectWrapper = new MapWrapper(this, (Map)object);
} else if (object instanceof Collection) {
this.objectWrapper = new CollectionWrapper(this, (Collection)object);
} else {
this.objectWrapper = new BeanWrapper(this, object);
}
}
可以看出这个MetaObject也是个将构造器私有的特殊单例模式,大致分析了一下就用下面的UML图画出
2.2 Tomcat源码中门面模式体现
tomcat中山使用了大量的外观模式,因为Tomcat中有很多不同组件,每个组件要相互通信,但是又不能将自己内部数据过多的暴露给其他组件。用门面模式隔离数据是个很好的方法。
下面是Request上使用的门面模式:
使用过Servlet的人都清楚,除了要在web.xml做相应的配置外,还需继承一个叫HttpServlet的抽象类,并且重写doGet与doPost方法(当然只重写service方法也是可以的)。
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
this.doPost(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
}
}
可以看出doGet与doPost方法有两个参数,参数类型是接口HttpServletRequest与接口HttpServletResponse,那么从Tomcat中传递过来的真实类型到底是什么呢?通过debug会发现,在真正调用TestServlet类之前,会经过很多Tomcat中的方法。如下图所示
注意红色方框圈中的类,StandardWrapperValue类中的invoke方法225行代码如下:
filterChain.doFilter
(request.getRequest(), response.getResponse());
在StandardWrapperValue类中并没有直接将Request对象与Response对象传递给ApplicationFilterChain类的doFilter方法,传递的是RequestFacade与ResponseFacade对象,为什么这么说呢,看一下request.getRequest()与response.getResponse()方法就真相大白了。
Request类
public HttpServletRequest getRequest() {
if (facade == null) {
facade = new RequestFacade(this);
}
return facade;
}
Response类
public HttpServletResponse getResponse() {
if (facade == null) {
facade = new ResponseFacade(this);
}
return (facade);
}
可以看到它们返回都是各自的一个门面类,那么这样做有什么好处呢?
Request对象中的很多方法都是内部组件之间相互交互时使用的,比如setComet、setRequestedSessionId等方法(这里就不一一列举了)。这些方法并不对外部公开,但是又必须设置为public,因为还需要跟内部组件之间交互使用。最好的解决方法就是通过使用一个Facade类,将与内部组件之间交互使用的方法屏蔽掉,只提供给外部程序感兴趣的方法。
如果不使用Facade类,直接传递的是Request对象和Response对象,那么熟悉容器内部运作的程序员可以分别把ServletRequest和ServletResponse对象向下转换为Request和Response,并调用它们的公共方法。比如拥有Request对象,就可以调用setComet、setRequestedSessionId等方法,这会危害安全性。
3、门面模式优缺点及使用场景
3.1 优点
松耦合
用户与子系统解耦,屏蔽子系统;可以提高子系统的独立性;使用简单
简化用户与子系统的依赖关系;
用户只与门面对接,有统一的入口;不需要知道所有子系统及内部构造;更好的划分访问层次
通过合理使用Facade,可以帮助我们更好地划分访问的层次。有些方法是对系统外的,有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中,这样既方便客户端使用,也很好地隐藏了内部的细节。
3.2 缺点
- 不规范的编程方式
没有面向抽象编程,而是通过增加中介层,转换服务提供方的服务接口;
不符合开闭原则,如果要改东西很麻烦,继承重写都不合适。
3.3 注意事项
在层次化结构中,可以使用外观模式定义系统中每一层的入口。
3.4 使用场景
- 为复杂的模块或子系统提供外界访问的模块。
- 子系统相对独立。
- 预防低水平人员带来的风险。
参考文章:
https://www.cnblogs.com/java-my-life/archive/2012/05/02/2478101.html
https://blog.csdn.net/yangspgao/article/details/80602794