行为型模式：责任链模式(Chain of Responsibility Pattern)

一、设计模式的分类

(如果以前看过关于设计模式的分类的话，这部分可以忽略！)

经过很多大神的总结，目前Java中一共23种经典的设计模式！

按照目的，设计模式可以分为以下三种用途：

1.创建型模式：用来处理对象的创建过程

2.结构型模式：用来处理类或者对象的组合

3.行为型模式：用来对类或对象怎样交互和怎样分配职责进行描述

创建型模式用来处理对象的创建过程，主要包含以下5种设计模式：

 工厂方法模式（Factory Method Pattern）

 抽象工厂模式（Abstract Factory Pattern）

 建造者模式（Builder Pattern）

 原型模式（Prototype Pattern）

 单例模式（Singleton Pattern）

结构型模式用来处理类或者对象的组合，主要包含以下7种设计模式：

 适配器模式（Adapter Pattern）

 桥接模式（Bridge Pattern）

 组合模式（Composite Pattern）

 装饰者模式（Decorator Pattern）

 外观模式（Facade Pattern）

 享元模式（Flyweight Pattern）

 代理模式（Proxy Pattern）

行为型模式用来对类或对象怎样交互和怎样分配职责进行描述，主要包含以下11种设计模式：

 责任链模式（Chain of Responsibility Pattern）

 命令模式（Command Pattern

 解释器模式（Interpreter Pattern）

 迭代器模式（Iterator Pattern）

 中介者模式（Mediator Pattern）

 备忘录模式（Memento Pattern）

 观察者模式（Observer Pattern）

 状态模式（State Pattern）

 策略模式（Strategy Pattern）

 模板方法模式（Template Method Pattern）

 访问者模式（Visitor Pattern） 

本篇文章主要为讲解一下责任链模式(Chain of Responsibility Pattern)！

注：概念性的东西可以忽略不看，可以在看完例子以后再看概念，这样更有利于理解！

二、责任链模式概述

(注：建议没有看过责任链模式的朋友们，先看实例，然后再看枯燥的概念)

1、概述：

在责任链模式里，有每一个对象对其下家的引用而连接起来形成一条链。

请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。

2、简单的类图：

3、角色定义：

●抽象处理者(Handler)角色：

定义出一个处理请求的接口。如果需要，接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。上图中Handler类的聚合关系给出了具体子类对下家的引用，抽象方法handleRequest()规范了子类处理请求的操作。

●具体处理者(ConcreteHandler)角色：

具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。

4、示例代码：

抽象处理者角色：

public abstract class Handler {    /**     * 持有后继的责任对象     */    protected Handler successor;    /**     * 示意处理请求的方法，虽然这个示意方法是没有传入参数的     * 但实际是可以传入参数的，根据具体需要来选择是否传递参数     */    public abstract void handleRequest();    /**     * 取值方法     */    public Handler getSuccessor() {        return successor;    }    /**     * 赋值方法，设置后继的责任对象     */    public void setSuccessor(Handler successor) {        this.successor = successor;    }}

具体处理者角色：

public class ConcreteHandler extends Handler {    /**     * 处理方法，调用此方法处理请求     */    @Override    public void handleRequest() {        /**         * 判断是否有后继的责任对象         * 如果有，就转发请求给后继的责任对象         * 如果没有，则处理请求         */        if(getSuccessor() != null)        {                        System.out.println("放过请求");            getSuccessor().handleRequest();                    }else        {                        System.out.println("处理请求");        }    }}

客户端类：

public class Client {    public static void main(String[] args) {        //组装责任链        Handler handler1 = new ConcreteHandler();        Handler handler2 = new ConcreteHandler();        handler1.setSuccessor(handler2);        //提交请求        handler1.handleRequest();    }}

客户端创建了两个处理者对象handler1、handler2，并指定handler1的下家是handler2，而handler2没有下家。

因此，第一个处理者对象接到请求后，会将请求传递给第二个处理者对象。由于第二个处理者对象没有下家，于是自行处理请求。

5、责任链模式的缺点：

handler1有可能在完成传递工作以后就成为垃圾对象，也就是说它在实际的处理中并没有发挥任何作用，如果责任链较长的话，就会长生很多垃圾对象，这就是责任链的最大缺点。

6、责任链模式灵活在哪里：

1. 它可以改变内部的传递规则。

比如：在公司，项目经理完全可以跳过人事部到那一关直接找到总经理。

每个人都可以去动态地指定他的继任者。

2. 可以从职责链任何一关开始。

如果项目经理不在，那么完全先找项目经理的上级处理问题

3. 我们来比较一下，用责任链和不用责任链的区别：

不用责任链时，我们需要和公司的每个层级都发生耦合关系。如果反映在代码上即使我们需要在一个类中去写上很多丑陋的if….else语句。

如果用了职责链，相当于我们面对的是一个黑箱，我们只需要认识其中的一个部门，然后让黑箱内部去负责传递就好了。

7、责任链模式的扩展----树状链结构：

责任链可能是一条直线、一个环链或者一个树结构的一部分。

之前看到的都是一些单链结构，但是其实在很多情况下，每一个节点都对应着很多其他的部分。

 

那么这样，我们的每一个节点都可以使用一个List来维护他节点的下一节点，甚至可以用组合模式来分别设计每一节点。

8、责任链模式必须有一个root类型的对象：

在我们的责任链中应该有一个能够想root类型一样的对象，这个对象有绝对的权限去处理任何的事情。

9、纯与不纯的概念：

一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又把责任向下传的情况。

在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收，而且每个处理者可以只处理请求的一部分

纯的责任链模式的实际例子很难找到，一般看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式，这也许是有道理的。但是在实际的系统里，纯的责任链很难找到。如果坚持责任链不纯便不是责任链模式，那么责任链模式便不会有太大意义了。

10、优点：

1、降低耦合度：该模式使得一个对象无需知道是其他哪一个对象处理其请求。对象仅需知道该请求会被“正确”地处理。接收者和发送者都没有对方的明确的信息，且链中的对象不需知道链的结构。

2、职责链可简化对象的相互连接 。它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。

3、增强了给对象指派职责(Resonsibility)的灵活性 ：当在对象中分派职责时，职责链给你更多的灵活性。你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。

4、增加新的请求处理类很方便

下面的例子表示没什么心思看！大家可以参考一下！

来自：http://www.cnblogs.com/java-my-life/archive/2012/05/28/2516865.html

责任链模式在Tomcat中的应用

　　众所周知Tomcat中的Filter就是使用了责任链模式，创建一个Filter除了要在web.xml文件中做相应配置外，还需要实现javax.servlet.Filter接口。

public class TestFilter implements Filter{    public void doFilter(ServletRequest request, ServletResponse response,            FilterChain chain) throws IOException, ServletException {                chain.doFilter(request, response);    }    public void destroy() {    }    public void init(FilterConfig filterConfig) throws ServletException {    }}

　　使用DEBUG模式所看到的结果如下

　　其实在真正执行到TestFilter类之前，会经过很多Tomcat内部的类。顺带提一下其实Tomcat的容器设置也是责任链模式，注意被红色方框所圈中的类，从Engine到Host再到Context一直到Wrapper都是通过一个链传递请求。被绿色方框所圈中的地方有一个名为ApplicationFilterChain的类，ApplicationFilterChain类所扮演的就是抽象处理者角色，而具体处理者角色由各个Filter扮演。

　　第一个疑问是ApplicationFilterChain将所有的Filter存放在哪里？

　　答案是保存在ApplicationFilterChain类中的一个ApplicationFilterConfig对象的数组中。

    /**     * Filters.     */    private ApplicationFilterConfig[] filters =         new ApplicationFilterConfig[0];

　　那ApplicationFilterConfig对象又是什么呢？

　   ApplicationFilterConfig是一个Filter容器。以下是ApplicationFilterConfig类的声明：

/** * Implementation of a <code>javax.servlet.FilterConfig</code> useful in * managing the filter instances instantiated when a web application * is first started. * * @author Craig R. McClanahan * @version $Id: ApplicationFilterConfig.java 1201569 2011-11-14 01:36:07Z kkolinko $ */

　　当一个web应用首次启动时ApplicationFilterConfig会自动实例化，它会从该web应用的web.xml文件中读取配置的Filter的信息，然后装进该容器。

　　刚刚看到在ApplicationFilterChain类中所创建的ApplicationFilterConfig数组长度为零，那它是在什么时候被重新赋值的呢？

    private ApplicationFilterConfig[] filters =         new ApplicationFilterConfig[0];

　　是在调用ApplicationFilterChain类的addFilter()方法时。

    /**     * The int which gives the current number of filters in the chain.     */    private int n = 0;

    public static final int INCREMENT = 10;

    void addFilter(ApplicationFilterConfig filterConfig) {        // Prevent the same filter being added multiple times        for(ApplicationFilterConfig filter:filters)            if(filter==filterConfig)                return;        if (n == filters.length) {            ApplicationFilterConfig[] newFilters =                new ApplicationFilterConfig[n + INCREMENT];            System.arraycopy(filters, 0, newFilters, 0, n);            filters = newFilters;        }        filters[n++] = filterConfig;    }

　　变量n用来记录当前过滤器链里面拥有的过滤器数目，默认情况下n等于0，ApplicationFilterConfig对象数组的长度也等于0，所以当第一次调用addFilter()方法时，if (n == filters.length)的条件成立，ApplicationFilterConfig数组长度被改变。之后filters[n++] = filterConfig;将变量filterConfig放入ApplicationFilterConfig数组中并将当前过滤器链里面拥有的过滤器数目+1。

　　那ApplicationFilterChain的addFilter()方法又是在什么地方被调用的呢？

　　是在ApplicationFilterFactory类的createFilterChain()方法中。

  1     public ApplicationFilterChain createFilterChain  2         (ServletRequest request, Wrapper wrapper, Servlet servlet) {  3   4         // get the dispatcher type  5         DispatcherType dispatcher = null;   6         if (request.getAttribute(DISPATCHER_TYPE_ATTR) != null) {  7             dispatcher = (DispatcherType) request.getAttribute(DISPATCHER_TYPE_ATTR);  8         }  9         String requestPath = null; 10         Object attribute = request.getAttribute(DISPATCHER_REQUEST_PATH_ATTR); 11          12         if (attribute != null){ 13             requestPath = attribute.toString(); 14         } 15          16         // If there is no servlet to execute, return null 17         if (servlet == null) 18             return (null); 19  20         boolean comet = false; 21          22         // Create and initialize a filter chain object 23         ApplicationFilterChain filterChain = null; 24         if (request instanceof Request) { 25             Request req = (Request) request; 26             comet = req.isComet(); 27             if (Globals.IS_SECURITY_ENABLED) { 28                 // Security: Do not recycle 29                 filterChain = new ApplicationFilterChain(); 30                 if (comet) { 31                     req.setFilterChain(filterChain); 32                 } 33             } else { 34                 filterChain = (ApplicationFilterChain) req.getFilterChain(); 35                 if (filterChain == null) { 36                     filterChain = new ApplicationFilterChain(); 37                     req.setFilterChain(filterChain); 38                 } 39             } 40         } else { 41             // Request dispatcher in use 42             filterChain = new ApplicationFilterChain(); 43         } 44  45         filterChain.setServlet(servlet); 46  47         filterChain.setSupport 48             (((StandardWrapper)wrapper).getInstanceSupport()); 49  50         // Acquire the filter mappings for this Context 51         StandardContext context = (StandardContext) wrapper.getParent(); 52         FilterMap filterMaps[] = context.findFilterMaps(); 53  54         // If there are no filter mappings, we are done 55         if ((filterMaps == null) || (filterMaps.length == 0)) 56             return (filterChain); 57  58         // Acquire the information we will need to match filter mappings 59         String servletName = wrapper.getName(); 60  61         // Add the relevant path-mapped filters to this filter chain 62         for (int i = 0; i < filterMaps.length; i++) { 63             if (!matchDispatcher(filterMaps[i] ,dispatcher)) { 64                 continue; 65             } 66             if (!matchFiltersURL(filterMaps[i], requestPath)) 67                 continue; 68             ApplicationFilterConfig filterConfig = (ApplicationFilterConfig) 69                 context.findFilterConfig(filterMaps[i].getFilterName()); 70             if (filterConfig == null) { 71                 // FIXME - log configuration problem 72                 continue; 73             } 74             boolean isCometFilter = false; 75             if (comet) { 76                 try { 77                     isCometFilter = filterConfig.getFilter() instanceof CometFilter; 78                 } catch (Exception e) { 79                     // Note: The try catch is there because getFilter has a lot of  80                     // declared exceptions. However, the filter is allocated much 81                     // earlier 82                     Throwable t = ExceptionUtils.unwrapInvocationTargetException(e); 83                     ExceptionUtils.handleThrowable(t); 84                 } 85                 if (isCometFilter) { 86                     filterChain.addFilter(filterConfig); 87                 } 88             } else { 89                 filterChain.addFilter(filterConfig); 90             } 91         } 92  93         // Add filters that match on servlet name second 94         for (int i = 0; i < filterMaps.length; i++) { 95             if (!matchDispatcher(filterMaps[i] ,dispatcher)) { 96                 continue; 97             } 98             if (!matchFiltersServlet(filterMaps[i], servletName)) 99                 continue;100             ApplicationFilterConfig filterConfig = (ApplicationFilterConfig)101                 context.findFilterConfig(filterMaps[i].getFilterName());102             if (filterConfig == null) {103                 // FIXME - log configuration problem104                 continue;105             }106             boolean isCometFilter = false;107             if (comet) {108                 try {109                     isCometFilter = filterConfig.getFilter() instanceof CometFilter;110                 } catch (Exception e) {111                     // Note: The try catch is there because getFilter has a lot of 112                     // declared exceptions. However, the filter is allocated much113                     // earlier114                 }115                 if (isCometFilter) {116                     filterChain.addFilter(filterConfig);117                 }118             } else {119                 filterChain.addFilter(filterConfig);120             }121         }122 123         // Return the completed filter chain124         return (filterChain);125 126     }

　　可以将如上代码分为两段，51行之前为第一段，51行之后为第二段。

　　第一段的主要目的是创建ApplicationFilterChain对象以及一些参数设置。

　　第二段的主要目的是从上下文中获取所有Filter信息，之后使用for循环遍历并调用filterChain.addFilter(filterConfig);将filterConfig放入ApplicationFilterChain对象的ApplicationFilterConfig数组中。

　　那ApplicationFilterFactory类的createFilterChain()方法又是在什么地方被调用的呢？

　　是在StandardWrapperValue类的invoke()方法中被调用的。

　　

　　由于invoke()方法较长，所以将很多地方省略。

    public final void invoke(Request request, Response response)        throws IOException, ServletException {   ...省略中间代码
　　　　 // Create the filter chain for this request        ApplicationFilterFactory factory =            ApplicationFilterFactory.getInstance();        ApplicationFilterChain filterChain =            factory.createFilterChain(request, wrapper, servlet);　　...省略中间代码         filterChain.doFilter(request.getRequest(), response.getResponse());　　...省略中间代码    }

　　那正常的流程应该是这样的：

　　在StandardWrapperValue类的invoke()方法中调用ApplicationFilterChai类的createFilterChain()方法———>在ApplicationFilterChai类的createFilterChain()方法中调用ApplicationFilterChain类的addFilter()方法———>在ApplicationFilterChain类的addFilter()方法中给ApplicationFilterConfig数组赋值。

　　根据上面的代码可以看出StandardWrapperValue类的invoke()方法在执行完createFilterChain()方法后，会继续执行ApplicationFilterChain类的doFilter()方法，然后在doFilter()方法中会调用internalDoFilter()方法。

　　以下是internalDoFilter()方法的部分代码

        // Call the next filter if there is one        if (pos < n) {
　　　　　　　//拿到下一个Filter，将指针向下移动一位
            //pos它来标识当前ApplicationFilterChain（当前过滤器链）执行到哪个过滤器            ApplicationFilterConfig filterConfig = filters[pos++];            Filter filter = null;            try {
　　　　　　　　　 //获取当前指向的Filter的实例                filter = filterConfig.getFilter();                support.fireInstanceEvent(InstanceEvent.BEFORE_FILTER_EVENT,                                          filter, request, response);                                if (request.isAsyncSupported() && "false".equalsIgnoreCase(                        filterConfig.getFilterDef().getAsyncSupported())) {                    request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,                            Boolean.FALSE);                }                if( Globals.IS_SECURITY_ENABLED ) {                    final ServletRequest req = request;                    final ServletResponse res = response;                    Principal principal =                         ((HttpServletRequest) req).getUserPrincipal();                    Object[] args = new Object[]{req, res, this};                    SecurityUtil.doAsPrivilege                        ("doFilter", filter, classType, args, principal);                                    } else {
　　　　　　　　　　　　//调用Filter的doFilter()方法                      filter.doFilter(request, response, this);                }

　　这里的filter.doFilter(request, response, this);就是调用我们前面创建的TestFilter中的doFilter()方法。而TestFilter中的doFilter()方法会继续调用chain.doFilter(request, response);方法，而这个chain其实就是ApplicationFilterChain,所以调用过程又回到了上面调用dofilter和调用internalDoFilter方法，这样执行直到里面的过滤器全部执行。

　　如果定义两个过滤器，则Debug结果如下：

参考资料：

http://www.cnblogs.com/java-my-life/archive/2012/05/28/2516865.html

http://www.cnblogs.com/kym/archive/2009/04/06/1430078.html