Tomcat中的Request & Response 设计结构

老版Tomcat使用catalina作为其连接器和容器的架构，当一个request请求到达时，Tomcat会对其做一系列的封装，并传递给容器进行处理，处理完之后，又会有一些解析工作来获取相应的response。

这里简单的介绍一下request在catalina中的体系结构。

我们都知道当我们进行web开发时，一个servlet只会接收类型为HttpServletRequest的对象，并返回类型为HttpServletResponse的结果。两个类中分别包含了许多web开发人员需要调用的方法，通常这些方法足够使用。

然后作为web container，Tomcat还需要在request中保存许多内部信息及使用方法，这些信息和方法不应该暴露给web开发人员，否则会造成不必要的麻烦。

那么，Tomcat中是如何实现只向开发人员提供有限接口，而内部提供更多接口的呢？

我们以Request为例子来看：
[img]http://dl.iteye.com/upload/attachment/483078/84481d0d-b513-33b7-b342-7b03409f9975.jpg[/img]
从这张图看，整个request的设计是相当复杂（这还不是全部，有些内容已经被省略掉），我们先看最基础的四个接口:

ServletRequest: 这个接口来自javax包，是JSP Spec中定义必须要实现的。
Request: Catalina内部的Request接口，为ServletRequest提供了许多补充方法，供 Catalina内部使用。
HttpServletRequest: 来自javax包，是JSP Spec中定义作为Http的request必须要实现的。
HttpRequest: Catalina内部的Request接口，为HttpServletRequest提供了许多补充方法，供Catalina内部使用。

整个设计中共用到了三种设计模式：

Default Pattern缺省模式，实际上这本身并不能算是一种模式，最多只能是一种编程方法，对于接口的所有子类，提供一个默认实现，在这里就是RequestBase及HttpRequestBase所做的工作，HttpRquestBase向HttpRquestImpl提供了HttpRequest和HttpServletRequest的默认实现。这样以后添加新的继承就只需要实现几个方法。

Adapter Pattern适配器模式，我们已经知道HttpRequestImpl中包含了HttpRequest和HttpServletRequest定义的所有方法的实现，然而对于Catalina组件，他们并不需要知道任何关于HttpServletRequest接口中定义的内容。因此，我们可以通过适配器模式将任何继承了HttpRequest和HttpServletRequest的类封装起来，并只提供HttpRequest提供的接口（可以看到HttpRequestWrapper继承HttpRequest）。

Facade Pattern门面模式，门面模式将内部复杂的实现隐藏起来，并提供一个简单的接口给外部的用户使用。在这里，HttpRequestFacade类将只提供HttpServletRequest中定义的方法给web开发人员。

从某种角度上讲，适配器模式和门面模式有一定的类似，都是将已有接口进行封装，并提供新的接口，然而适配器着重于将一个接口转换成另一个接口，门面模式则着重于将复杂的内部实现隐藏起来，提供一个简单的通用接口。

然而在我们这个例子中，似乎并没有这些所谓的区别，两种实现方法几乎一致。