在阎宏博士的《JAVA与模式》一书中开头是这样描述责任链（Chain of Responsibility）模式的： 　　责任链模式是一种对象的行为模式。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。 [b]从击鼓传花谈起[/b] 　　击鼓传花是一种热闹而又紧张的饮酒游戏。在酒宴上宾客依次坐定位置，由一人击鼓，击鼓的地方与传花的地方是分开的，以示公正。开始击鼓时，花束就开始依次传递，鼓声一落，如果花束在某人手中，则该人就得饮酒。 　　比如说，贾母、贾赦、贾政、贾宝玉和贾环是五个参加击鼓传花游戏的传花者，他们组成一个环链。击鼓者将花传给贾母，开始传花游戏。花由贾母传给贾赦，由贾赦传给贾政，由贾政传给贾宝玉，又贾宝玉传给贾环，由贾环传回给贾母，如此往复，如下图所示。当鼓声停止时，手中有花的人就得执行酒令。 [img]http://files.jb51.net/file_images/article/201504/20154290718700.png?2015329734[/img] 　　击鼓传花便是责任链模式的应用。责任链可能是一条直线、一个环链或者一个树结构的一部分。 [b]责任链模式的结构[/b] 　　下面使用了一个责任链模式的最简单的实现。 [img]http://files.jb51.net/file_images/article/201504/20154290746364.png?2015329753[/img] 责任链模式涉及到的角色如下所示： 　　●　　抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。上图中Handler类的聚合关系给出了具体子类对下家的引用，抽象方法handleRequest()规范了子类处理请求的操作。 　　●　　具体处理者(ConcreteHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。 [b]源代码[/b] [b]　　抽象处理者角色 [/b] [b]具体处理者角色 [/b] [b]客户端类 [/b] 　　可以看出，客户端创建了两个处理者对象，并指定第一个处理者对象的下家是第二个处理者对象，而第二个处理者对象没有下家。然后客户端将请求传递给第一个处理者对象。 　　由于本示例的传递逻辑非常简单：只要有下家，就传给下家处理；如果没有下家，就自行处理。因此，第一个处理者对象接到请求后，会将请求传递给第二个处理者对象。由于第二个处理者对象没有下家，于是自行处理请求。活动时序图如下所示。 [img]http://files.jb51.net/file_images/article/201504/20154290815118.png?2015329821[/img] [b]使用场景[/b] 　　来考虑这样一个功能:申请聚餐费用的管理。 　　很多公司都是这样的福利，就是项目组或者是部门可以向公司申请一些聚餐费用，用于组织项目组成员或者是部门成员进行聚餐活动。 　　申请聚餐费用的大致流程一般是：由申请人先填写申请单，然后交给领导审批，如果申请批准下来，领导会通知申请人审批通过，然后申请人去财务领取费用，如果没有批准下来，领导会通知申请人审批未通过，此事也就此作罢。 　　不同级别的领导，对于审批的额度是不一样的，比如，项目经理只能审批500元以内的申请；部门经理能审批1000元以内的申请；而总经理可以审核任意额度的申请。 　　也就是说，当某人提出聚餐费用申请的请求后，该请求会经由项目经理、部门经理、总经理之中的某一位领导来进行相应的处理，但是提出申请的人并不知道最终会由谁来处理他的请求，一般申请人是把自己的申请提交给项目经理，或许最后是由总经理来处理他的请求。 　　 　　可以使用责任链模式来实现上述功能：当某人提出聚餐费用申请的请求后，该请求会在 项目经理—〉部门经理—〉总经理 这样一条领导处理链上进行传递，发出请求的人并不知道谁会来处理他的请求，每个领导会根据自己的职责范围，来判断是处理请求还是把请求交给更高级别的领导，只要有领导处理了，传递就结束了。 　　需要把每位领导的处理独立出来，实现成单独的职责处理对象，然后为它们提供一个公共的、抽象的父职责对象，这样就可以在客户端来动态地组合职责链，实现不同的功能要求了。 [img]http://files.jb51.net/file_images/article/201504/20154290832056.png?2015329839[/img] [b]源代码[/b] [b]　　抽象处理者角色类 [/b] [b]具体处理者角色 [/b] [b]客户端类[/b] 运行结果如下所示： [img]http://files.jb51.net/file_images/article/201504/20154290900421.png?201532997[/img] [b]纯的与不纯的责任链模式[/b] 　　一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又 把责任向下传的情况。 　　在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收。 　　纯的责任链模式的实际例子很难找到，一般看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式，这也许是有道理的。但是在实际的系统里，纯的责任链很难找到。如果坚持责任链不纯便不是责任链模式，那么责任链模式便不会有太大意义了。 [b]责任链模式在Tomcat中的应用[/b] 　　众所周知Tomcat中的Filter就是使用了责任链模式，创建一个Filter除了要在web.xml文件中做相应配置外，还需要实现javax.servlet.Filter接口。 　使用DEBUG模式所看到的结果如下 [img]http://files.jb51.net/file_images/article/201504/20154290922690.png?2015329928[/img] 其实在真正执行到TestFilter类之前，会经过很多Tomcat内部的类。顺带提一下其实Tomcat的容器设置也是责任链模式，注意被红色方框所圈中的类，从Engine到Host再到Context一直到Wrapper都是通过一个链传递请求。被绿色方框所圈中的地方有一个名为ApplicationFilterChain的类，ApplicationFilterChain类所扮演的就是抽象处理者角色，而具体处理者角色由各个Filter扮演。 　　第一个疑问是ApplicationFilterChain将所有的Filter存放在哪里？ 　　答案是保存在ApplicationFilterChain类中的一个ApplicationFilterConfig对象的数组中。 　那ApplicationFilterConfig对象又是什么呢？ 　   ApplicationFilterConfig是一个Filter容器。以下是ApplicationFilterConfig类的声明： 当一个web应用首次启动时ApplicationFilterConfig会自动实例化，它会从该web应用的web.xml文件中读取配置的Filter的信息，然后装进该容器。 　　刚刚看到在ApplicationFilterChain类中所创建的ApplicationFilterConfig数组长度为零，那它是在什么时候被重新赋值的呢？ 是在调用ApplicationFilterChain类的addFilter()方法时。 变量n用来记录当前过滤器链里面拥有的过滤器数目，默认情况下n等于0，ApplicationFilterConfig对象数组的长度也等于0，所以当第一次调用addFilter()方法时，if (n == filters.length)的条件成立，ApplicationFilterConfig数组长度被改变。之后filters[n++] = filterConfig;将变量filterConfig放入ApplicationFilterConfig数组中并将当前过滤器链里面拥有的过滤器数目+1。 　　那ApplicationFilterChain的addFilter()方法又是在什么地方被调用的呢？ 　　是在ApplicationFilterFactory类的createFilterChain()方法中。 可以将如上代码分为两段，51行之前为第一段，51行之后为第二段。 　　第一段的主要目的是创建ApplicationFilterChain对象以及一些参数设置。 　　第二段的主要目的是从上下文中获取所有Filter信息，之后使用for循环遍历并调用filterChain.addFilter(filterConfig);将filterConfig放入ApplicationFilterChain对象的ApplicationFilterConfig数组中。 　　那ApplicationFilterFactory类的createFilterChain()方法又是在什么地方被调用的呢？ 是在StandardWrapperValue类的invoke()方法中被调用的。 [img]http://files.jb51.net/file_images/article/201504/20154290949388.png?2015329958[/img] 　　由于invoke()方法较长，所以将很多地方省略。 　那正常的流程应该是这样的： 　　在StandardWrapperValue类的invoke()方法中调用ApplicationFilterChai类的createFilterChain()方法———>在ApplicationFilterChai类的createFilterChain()方法中调用ApplicationFilterChain类的addFilter()方法———>在ApplicationFilterChain类的addFilter()方法中给ApplicationFilterConfig数组赋值。 [img]http://files.jb51.net/file_images/article/201504/20154291007417.png?20153291014[/img] 根据上面的代码可以看出StandardWrapperValue类的invoke()方法在执行完createFilterChain()方法后，会继续执行ApplicationFilterChain类的doFilter()方法，然后在doFilter()方法中会调用internalDoFilter()方法。 　　以下是internalDoFilter()方法的部分代码 这里的filter.doFilter(request, response, this);就是调用我们前面创建的TestFilter中的doFilter()方法。而TestFilter中的doFilter()方法会继续调用chain.doFilter(request, response);方法，而这个chain其实就是ApplicationFilterChain,所以调用过程又回到了上面调用dofilter和调用internalDoFilter方法，这样执行直到里面的过滤器全部执行。 　　如果定义两个过滤器，则Debug结果如下： [img]http://files.jb51.net/file_images/article/201504/20154291020440.png?20153291027[/img]