java开源文档大全致力于打造中国最大最全的开源文档,它提供了最全面最权威的开源资料,同时为大家提供一个交流的平台,如果您有好的想法,欢迎您投稿.
坛子上讨论设计模式的也挺多的，但是关于这个责任链模式还没有人提及，我对责任链模式也有些疑惑，我的疑惑是，责任链真的是一种设计模式吗，我为什么有这种疑惑呢，因为在我用到和学习的责任链一共有3种，但是n多的书上就是那么一种最基础的责任链模式。在我的心里，只要能完成责任传递的都可以称之为责任链。当然也有可能我的这种理解是错误的，但如果我的理解是错误的，那么就是说每种模式都是有固定形态的，简单的模式是有固定形态，这我承认，但是如果说所有的模式都有固定的形态我不太相信，下面我就用文章来说明我的观点。
下面我详细说说我眼里的3种责任链模式：
1， 基本版责任链
这里所谓的基本责任链模式是指书上网上到处都有的责任链模式，其实这种模式网上到处都有，我就炒炒冷菜。让我们来看看下面这个关于它的uml图
图1，见附件
这是最简单的责任链模式，但是事实上我很少看到它在真实的系统中被使用（也有可能经验不足）。大家看到，我在图中给接口和类取的名字是Filter，没错，这个模式待会将会和正真的Filter相比较。下面我们就看看在spring中如何实现这么一种责任链模式。
首先是Filter的接口如下：
代码
接着是一个抽象类，用来hold住下一个Filter实例的引用
代码
接着就是3个具体的filter了。同样，让我们来看一下这3个具体的filter的代码:
1权限检查filter
代码
2url重写filter
代码
3其他的filter
代码
3个具体的filter有了之后就等组装“链”了。我们看看spring中的配置：
代码
O了，就这样，当你从spring的的context中得到这个authFilter的时候，你其实得到了一条链，当你调用authFilter的方法是，这个调用会沿着链向下传递。到目前为止，我们已经实现了一个很搓（差）的责任链了，现在如果你在使用struts framework frame1.x系列，那么你就可以把这个代码搬到struts framework frame1.x里，给action实现它自己的不依赖于servlet容器的拦截器了（当然如果是你真的想的话）。
众所周知的责任链成型了，但是你能忍受这种所谓的责任链模式吗，至少我不能，即使我使用struts framework frame1.x，我也不会傻到把上面这个破代码搬到项目里去的。那么就再让我们来看看第二种责任链模式吧
2， 混血版责任链(基于观察者的责任链)
我之前写了一篇关于观察者的文章（ http://www.javaeye.com/topic/102068 ），在这篇文章中，我曾经说过观察者稍微改一下就可以变成责任链，也就是说我们可以通过观察者来实现同上面一样的功能。这里我只简单描述一下如何用观察者来实现责任链。当然首先我们必须要理解观察者模式，如果不清楚观察者模式的就看http://www.javaeye.com/topic/102068 这篇文章吧。
如果说之前的那个责任链是通过nextFilter引用而形成的话，那么观察者模式中的观察者的集合也可以看作是一个链，只不过这个链上的每一个update方法都是要执行的，我们可以让它们某些执行某些不执行吗，当然可以了，只需要在写update方法的实现判断一下是否需要执行就行了，判断的条件就是update传进去的，比如说被观察者如下：
代码
两个观察者如下：
代码
和
代码
这样的话，每次通知观察者，在观察者列表中只有一个或多个观察者被执行了，如此一来，也实现了第一中观察者的功能。那么如果要为struts framework frame1.x实现不依赖于servlet容器的拦截器的时候我会用它吗？还是不会，因为虽然我也认为它是责任链，但事实上它更具备观察者的特征，比如说有一个列表，执行的时候需要遍历列表，并执行列表中对象的方法，这明显是观察者的特征。所以说它更像观察者，如果说观察者是父亲，责任链是母亲，那这个第二种责任链其实更像父亲。
虽然我还是不会用它来实现上面的需求，但是有一点我倒觉得这种用法比较像spring提供的事件机制，只不过在事件机制中是根据参数是否是属于某一类型（指instanceOf方法）来判断事件是否应该发生的，不管怎么说，都是用观察者模式来实现的（貌似我又在谈观察者的重要性了）。
其实上面的这个equals判断是可以用正则表达式来代替，也就是说每一个update方法执行之前可以先用正则表达式匹配一下参数是否符合要求，这样灵活性就更大了，在第3种责任链中，我将会用正则表达式来判断责任的传递。
接下来轮到第3种责任链了（口干舌燥，喝点水吧），
3， 潇洒版责任链
我们来看看所谓的潇洒版的责任链模式，如下图所示：
图2，见附件
很明显，这个图复杂多了，可以说这个责任链和基本版的责任链有本质的区别，他不是一个责任对象引用另外一个责任对象这种形式，通过这种形式形成了一条看不见的链。但是这够oo吗，所谓责任链，其实暗示着我们这里有两个类，一个是责任，一个是链，如果像基本版的责任链就只有一个责任类，通过责任之间的依赖形成了一个链。显然这种方式明显比不上潇洒版责任链，在这种责任链中，责任是一个对象，链也是一个对象。
我们来仔细看一下上面这个图，责任就是ConcreateHandler，链就是ConcreateHandlerChain，HandlerConfig是对责任的配置类，事实上链和责任之间的关系是靠HandlerConfig联系起来的。
首先我们来看一下链对象中的executeHandler()方法，这个方法是整个责任链的核心：
代码
值得注意的是这个方法中有一个递规操作用，它的作用是当前handler不被执行的话就去判断是否执行下一个handler，我对递规还是有点怕的，大家有其他方法吗
我们再来看看责任对象中的executeHandler方法，这个方法就是每个责任对象的行为：
代码
就是通过责任对象和链对象之间的重复调用，我们就实现了责任的传递，那为什么还需要一个config呢，这是因为责任链上的责任我认为应该是不带状态的，这个用户在写自己的责任对象的时候不需要考虑它的配置，因为通常它的配置是写在配置文件中的。我们来看一下config类：
代码
熟悉tomcat服务器的同学大概已经猜出来了，这种责任链事实上就是tomcat服务器中的filter，几乎一样的，那么让我们再看看测试方法：
代码
上面一些config对象的创建可以放到框架中，每个线程都创建一个EasyHandlerChain就行了，当然我们也可以把config对象创建所需要的配置放到annotation中去，但在这个例子中没有必要这样做。在测试方法中，每个config都设置了匹配表达式，每个chain对象都设置了匹配的值，简直和tomcat服务器的filter配置一摸一样是吗。
附件是上面3种责任链的源代码， 尤其是第3种，只看上面贴出来的代码不太容易理解，看看源代码，运行一下就明白了。
总结一下吧：我们可以看到，在责任链的实现中我们使用到3种模式，这也是我的疑惑，责任链是一种设计模式吗，我认为它不应该属于某一种模式，责任链是一种思想，这种思想凌驾于模式之上，我们可以用模式来实现这种思想。这就是我想说的，如果你觉的这种理解是不正确的，请务必说明理由。
[code][/code]
java开源文档研究struts,webwork,spring,tomcat,jboss,lucense,nutch,JUnit,eclipse......,如果您有什么意见,欢迎评论和留言. |
