粗浅看 Tomcat中设计模式分析

本文主要是介绍粗浅看 Tomcat中设计模式分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

简介

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 方法

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);}

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

2. 容器中的 start 方法

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);}

命令

前面把 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。只要涉及到这种有链式是处理流程这是一个非常值得借鉴的模式。