责任链模式

责任链模式（Chain of Responsibility）

感觉这种模式很有用的，深入学习学习。。。。

一、引言
初看责任链模式，心里不禁想起了一个以前听过的相声：看牙。说的是一个病人看牙的时候，医生不小心把拔下的一个牙掉进了病人嗓子里。病人因此楼上楼下的跑了好多科室，最后无果而终。
责任链模式就是这种“推卸”责任的模式，你的问题在我这里能解决我就解决，不行就把你推给另一个对象。至于到底谁解决了这个问题了呢？我管呢！

二、定义与结构
从名字上大概也能猜出这个模式的大概模样——系统中将会存在多个有类似处理能力的对象。当一个请求触发后，请求将在这些对象组成的链条中传递，直到找到最合适的“责任”对象，并进行处理。
《设计模式》中给它的定义如下：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
从定义上可以看出，责任链模式的提出是为了“解耦”，以应变系统需求的变更和不明确性。
下面是《设计模式》中给出的适用范围：
1) 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
2) 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
3) 可处理一个请求的对象集合应被动态指定。
责任链模式真的能给发送者和接收者之间解耦（这好像很神奇）吗？先来看下它的组成角色。这个问题我会在下面提及。
责任链模式由两个角色组成：
1) 抽象处理者角色（Handler）：它定义了一个处理请求的接口。当然对于链子的不同实现，也可以在这个角色中实现后继链。
2) 具体处理者角色（Concrete Handler）：实现抽象角色中定义的接口，并处理它所负责的请求。如果不能处理则访问它的后继者。
至于类图不放也罢。毕竟就是一个继承或者实现。

三、纯与不纯
责任链模式的纯与不纯的区别，就像黑猫、白猫的区别一样。不要刻意的去使自己的代码来符合一个模式的公式。只要能够使代码降低耦合、提高重用，满足系统需求并能很好的适应变化就好了。正所谓：管它黑猫白猫，抓住老鼠就是好猫！
纯的责任链模式，规定一个具体处理者角色只能对请求作出两种动作：自己处理；传给下家。不能出现处理了一部分，把剩下的传给了下家的情况。而且请求在责任链中必须被处理，而不能出现无果而终的结局。
反之，则就是不纯的责任链模式。
不纯的责任链模式还算是责任链模式吗？比如一个请求被捕获后，每个具体处理者都尝试去处理它，不管结果如何都将请求再次转发。我认为这种方式的实 现，算不算是责任链模式的一种倒不重要，重要的是我们也能从中体味到责任链模式的思想：通过将多个处理者之间建立联系，来达到请求与具体的某个处理者的解 耦。


坛子上讨论设计模式的也挺多的，但是关于这个责任链模式还没有人提及，我对责任链模式也有些疑惑，我的疑惑是，责任链真的是一种设计模式吗，我为什么有这 种疑惑呢，因为在我用到和学习的责任链一共有3种，但是n多的书上就是那么一种最基础的责任链模式。在我的心里，只要能完成责任传递的都可以称之为责任 链。当然也有可能我的这种理解是错误的，但如果我的理解是错误的，那么就是说每种模式都是有固定形态的，简单的模式是有固定形态，这我承认，但是如果说所 有的模式都有固定的形态我不太相信，下面我就用文章来说明我的观点。

下面我详细说说我眼里的3种责任链模式：
1， 基本版责任链
这里所谓的基本责任链模式是指书上网上到处都有的责任链模式，其实这种模式网上到处都有，我就炒炒冷菜。让我们来看看下面这个关于它的uml图。这是最简单的责任链模式，但是事实上我很少看到它在真实的系统中被使用（也有可能经验不足）。大家看到，我在图中给接口和类取的名字是Filter，没错，这个模式待会将会和正真的Filter相比较。下面我们就看看在spring中如何实现这么一种责任链模式。就这样，当你从spring的的context中得到这个authFilter的时候，你其实得到了一条链，当你调用authFilter的方法是，这个 调用会沿着链向下传递。到目前为止，我们已经实现了一个很搓（差）的责任链了，现在如果你在使用struts1.x系列，那么你就可以把这个代码搬到 struts1.x里，给action实现它自己的不依赖于servlet容器的拦截器了（当然如果是你真的想的话）。

众所周知的责任链成型了，但是你能忍受这种所谓的责任链模式吗，至少我不能，即使我使用struts1.x，我也不会傻到把上面这个破代码搬到项目里去的。那么就再让我们来看看第二种责任链模式吧。
2， 我之前写了一篇关于观察者的文章（ http://www.iteye.com/topic/102068 ），在这篇文章中，我曾经说过观察者稍微改一下就可以变成责任链，也就是说我们可以通过观察者来实现同上面一样的功能。这里我只简单描述一下如何用观察者来实现责任链。当然首先我们必须要理解观察者模式，如果不清楚观察者模式的就看http://www.iteye.com/topic/102068 这篇文章吧。

如果说之前的那个责任链是通过nextFilter引用而形成的话，那么观察者模式中的观察者的集合也可以看作是一个链，只不过这个链上的每一个 update方法都是要执行的，我们可以让它们某些执行某些不执行吗，当然可以了，只需要在写update方法的实现判断一下是否需要执行就行了，判断的 条件就是update传进去的，比如说被观察者如下：这样的话，每次通知观察者，在观察者列表中只有一个或多个观察者被执行了，如此一来，也实现了第一中观察者的功能。那么如果要为struts1.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种模式，这也是我的疑惑，责任链是一种设计模式吗，我认为它不应该属于某一种模式，责任链是一种 思想，这种思想凌驾于模式之上，我们可以用模式来实现这种思想。这就是我想说的，如果你觉的这种理解是不正确的，请务必说明理由。




评论
职责链和观察者有几个重要区别
1.从概念上讲,职责链是个有序的线性表,所有的节点每次都按固定的顺序被调用.而观察者则没有这个要求.
2.职责链各个节点可以相互影响,即在事件的传递过程中,可以对事件进行修改,甚至阻止事件的传递.而观察者不行.观察者要求每次事件发生所有的观察者都应该收到通知,并且通知内容相同.各个观察者应该彼此独立,并不知道彼此的存在.

搂主的第二中实现就是观察者者模式了，没有任何职责链的味道。各个observer之间彼此独立监听事件，事件发生后独自进行操作。
楼主第三种实现属于观察者模式加入ChangeManager.

http://www.iteye.com/topic/411182

见代码