您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
粗浅看 Tomcat中设计模式分析
 
作者:吴士龙  来源:博客  发布于:2016-10-27
   次浏览      
 

简介

Tomcat 中运用的许多经典设计模式,如模版模式、工厂模式和单例模式等。通过学习它们的实践运用能给我们以后的程序设计起到一定的借鉴作用。

外观

外观设计模式在 Tomcat 中有多处使用,在 Request 和Response对象封装中、StandardWrapper到 ServletConfig封装中、ApplicationContext到 ServletContext封装中等都用到了这种设计模式。

原理

这么多场合都用到了这种设计模式,那这种设计模式究竟能有什 么作用呢?顾名思义,就是将一个东西封装成一个外观好与人家更容易进行交流,就像一个国家的外交部一样。

这种设计模式主要用在一个大的系统中有多个子系统组成时,这 多个子系统肯定要涉及到相互通信,但是每个子系统又不能将自己的内部数据过多的暴露给其它系统,不然就没有必要划分子系统了。 每个子系统都会设计一个外观,把别的系统感兴趣的数据封装起来, 通过这个外观来进行访问。这就是外观设计模式存在的意义。

外观设计模式示意图如下:

Client只能访问到 Fa?ade中提供的数据是外观设计模式的关键,至 于 Client如何访问 Fa?ade和 Subsystem如何提供 Fa?ade 外观设 计模式并没有规定死。

Tomcat中的demo

Tomcat 中外观设计模式使用的很多,因为 Tomcat 中有很多不同组件,每个组件要相互交互数据,用外观模式隔离数据是个很好的方法。

下面是 Request 上使用的外观设计模式:

从图中可以看出 HttpRequestFacade类封装了 HttpRequest 接口能 够提供数据,通过 HttpRequestFacade访问到的数据都被代理到 HttpRequest 中,通常被封装的对象都被设为 Private或者 Protected 访问修饰,以防止在 Fa?ade 中被直接访问。

观察者

这种设计模式也是常用的设计方法通常也叫发布 -订阅模式,也 就是事件监听机制,通常在某个事件发生的前后会触发一些操作。

原理

观察者模式原理也很简单,就是你在做事的时候旁边总有一个人在盯着你,当你做的事情是它感兴趣的时候,它就会跟着做另外一 些事情。但是盯着你的人必须要到你那去登记,不然你无法通知它。 观察者模式通常包含下面这几个角色:

Subject 就是抽象主题:它负责管理所有观察者的引用,同时定义主要的事件操作。

ConcreteSubject 具体主题:它实现了抽象主题的所有定义的接口,当自己发生变 化时,会通知所有观察者。

Observer 观察者:监听主题发生变化相应的操作接口。

Tomcat中的demo

Tomcat 中观察者模式也有多处使用,前面讲的控制组件生命周期的 Lifecycle就是这种模式的体现,还有对 Servlet实例的创建、 Session的管理、Container等都是同样的原理。下面主要看一下 Lifecycle 的具体实现。

Lifecycle 的观察者模式结构图:

上面的结构图中,LifecycleListener代表的是抽象观察者,它定 义一个 lifecycleEvent方法,这个方法就是当主题变化时要执行的方 法。 ServerLifecycleListener代表的是具体的观察者,它实现了 LifecycleListener接口的方法,就是这个具体的观察者具体的实现方式。Lifecycle接口代表的是抽象主题,它定义了管理观察者的方法 和它要所做的其它方法。而 StandardServer代表的是具体主题,它 实现了抽象主题的所有方法。这里 Tomcat 对观察者做了扩展,增加了另外两个类:LifecycleSupport、LifecycleEvent,它们作为辅助类扩展了观察者的功能。LifecycleEvent使得可以定义事件类别,不 同的事件可区别处理,更加灵活。LifecycleSupport类代理了主题对 多观察者的管理,将这个管理抽出来统一实现,以后如果修改只要 修改 LifecycleSupport类就可以了,不需要去修改所有具体主题, 因为所有具体主题的对观察者的操作都被代理给 LifecycleSupport类了。这可以认为是观察者模式的改进版。

LifecycleSupport 调用观察者的方法代码如下:

1. LifecycleSupport 中的 fireLifecycleEvent 方法

<span style="font-size:18px;">public void fireLifecycleEvent(String type, Object data) {  

LifecycleEvent event = new LifecycleEvent(lifecycle, type, data);

LifecycleListener interested[] = null;

synchronized (listeners) {

interested = (LifecycleListener[]) listeners.clone();

}

for (int i = 0; i < interested.length; i++)

interested[i].lifecycleEvent(event);

}</span>

主题是怎么通知观察者呢?看下面代码:

2. 容器中的 start 方法

<span style="font-size:18px;">public void start() throws LifecycleException {  

lifecycle.fireLifecycleEvent(BEFORE_START_EVENT, null);

lifecycle.fireLifecycleEvent(START_EVENT, null);

started = true;

synchronized (services) {

for (int i = 0; i < services.length; i++) {

if (services[i] instanceof Lifecycle)

((Lifecycle) services[i]).start();

}

}

lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);

}</span>

命令

前面把 Tomcat中两个核心组件 Connector和 Container,比作一对夫妻。男的将接受过来的请求以命令的方式交给女主人。对应 到 Connector和 Container,Connector也是通过命令模式调用 Container的。

原理

命令模式主要作用就是封装命令,把发出命令的责任和执行命令 的责任分开。也是一种功能的分工。不同的模块可以对同一个命令做出不同解释。

下面是命令模式通常包含下面几个角色:

Client:创建一个命令,并决定接受者

Command 命令:命令接口定义一个抽象方法

ConcreteCommand:具体命令,负责调用接受者的相应操作

Invoker 请求者:负责调用命令对象执行请求

Receiver 接受者:负责具体实施和执行一次请求

Tomcat 中的demo

Tomcat中命令模式在 Connector和 Container组件之间有体现, Tomcat 作为一个应用服务器,无疑会接受到很多请求,如何分配和执行这些请求是必须的功能。

下面看一下 Tomcat 是如何实现命令模式的,下面是 Tomcat 命令 模式的结构图:

Connector 作为抽象请求者,HttpConnector作为具体请求者。 HttpProcessor作为命令。Container作为命令的抽象接受者, ContainerBase 作为具体的接受者。客户端就是应用服务器 Server组件了。Server 首先创建命令请求者HttpConnector对象,然后创建命令 HttpProcessor命令对象。再把命令对象交给命令接受者 ContainerBase 容器来处理命令。命令的最终是被 Tomcat 的 Container执行的。命令可以以队列的方式进来,Container也可以 以不同的方式来处理请求,如 HTTP1.0协议和 HTTP1.1的处理方 式就会不同。

职责链

Tomcat 中一个最容易发现的设计模式就是职责链模式,这个设 计模式也是Tomcat中 Container设计的基础,整个容器的就是通 过一个链连接在一起,这个链一直将请求正确的传递给最终处理请 求的那个 Servlet。

原理

职责链模式,就是很多对象有每个对象对其下家的引用而连接起 来形成一条链,请求在这条链上传递,直到链上的某个对象处理此请求,或者每个对象都可以处理请求,并传给下一家,直到最终链 上每个对象都处理完。这样可以不影响客户端而能够在链上增加任 意的处理节点。

通常职责链模式包含下面几个角色:

Handler(抽象处理者):定义一个处理请求的接口

ConcreteHandler(具体处理者):处理请求的具体类,或者传给下家

Tomcat 中的demo

在tomcat中这种设计模式几乎被完整的使用,tomcat的容器设置就是职责链模式,从 Engine 到 Host再到 Context一直到 Wrapper 都是通过一个链传递请求。

Tomcat 中职责链模式的类结构图如下:

上图基本描述了四个子容器使用职责链模式的类结构图,对应的 职责链模式的角色,Container扮演抽象处理者角色,具体处理者由 StandardEngine等子容器扮演。与标准的职责链不同的是,这里引 入了 Pipeline和 Valve接口。他们有什么作用呢?

实际上 Pipeline和 Valve是扩展了这个链的功能,使得在链往下 传递过程中,能够接受外界的干预。Pipeline就是连接每个子容器 的管子,里面传递的 Request和 Response对象好比管子里流的水, 而 Valve就是这个管子上开的一个个小口子,让你有机会能够接触 到里面的水,做一些额外的事情。

为了防止水被引出来而不能流到下一个容器中,每一段管子最后 总有一个节点保证它一定能流到下一个子容器,所以每个容器都有一个StandardXXXValve。只要涉及到这种有链式是处理流程这是一个非常值得借鉴的模式。

业务思想

Tomcat中的设计模式很值得研究学习,免得绕路去上学,搞不好成绩还低呢。

不知道有朋友看过《射雕英雄传》木?其中一段是讲黄蓉受伤去拜见南帝段皇爷治疗,途遇老顽童的老婆瑛姑,二人在茅屋内做算术题,瑛姑是闭门造车,而黄蓉是看黄老邪(也就是他老爸收集的书本),最后结果相信大家都知道:瑛姑pk失败。原因值得探究:时刻要站在巨人的肩膀上来学习。

   
次浏览       
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]

重构-使代码更简洁优美
Visitor Parttern
由表及里看模式
设计模式随笔系列
深入浅出设计模式-介绍
.NET中的设计模式
更多...   
相关培训课程

J2EE设计模式和性能调优
应用模式设计Java企业级应用
设计模式原理与应用
J2EE设计模式指南
单元测试+重构+设计模式
设计模式及其CSharp实现

某电力公司 设计模式原理
蓝拓扑 设计模式原理及应用
卫星导航 UML & OOAD
汤森路透研发中心 UML& OOAD
中达电通 设计模式原理
西门子 嵌入式设计模式
更多...