责任链模式

在以下条件下使用Responsibility 链：

? 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。

? 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。

?可动态指定一组对象处理请求。

抽象处理者角色(Handler:Approver):定义一个处理请求的接口，和一个后继连接(可选)

具体处理者角色(ConcreteHandler:President):处理它所负责的请求，可以访问后继者，如果可以处理请求则处理，否则将该请求转给他的后继者。

客户类(Client):向一个链上的具体处理者ConcreteHandler对象提交请求。

 

职责链模式的优点：

 

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

 

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

 

3) 增强了给对象指派职责( R e s p o n s i b i l i t y )的灵活性 ：当在对象中分派职责时，职责链给你更多的灵活性。你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。你可以将这种机制与静态的特例化处理对象的继承机制结合起来使用。

 

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

 

 

 

职责链模式的缺点:

 

1) ? 不能保证请求一定被接收。既然一个请求没有明确的接收者，那么就不能保证它一定会被处理 —该请求可能一直到链的末端都得不到处理。一个请求也可能因该链没有被正确配置而得不到处理。

 

2) ? 系统性能将受到一定影响，而且在进行代码调试时不太方便；可能会造成循环调用。

 

 

纯的职责链模式：一个具体处理者角色处理只能对请求作出两种行为中的一个：一个是自己处理（承担责任），另一个是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又将责任向下传的情况。请求在责任链中必须被处理，不能出现无果而终的结局。

反之就是不纯的职责链模式。  

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

假如在公司里，

如果你的请假时间小于0.5天，那么只需要向leader打声招呼就OK了。
如果0.5<请假天数<=3天，需要先leader打声招呼，要不然leader不知你跑哪里，然后部门经理直接签字。
如果3<请假天数 天，需要先leader打声招呼，然后到部门经理签字，最好总经经理确认签字，

当你看到这情况后你心里是不是已经有了自己的想法了?写一系列的if语句来一条条的判断.但这样的写法虽然可以实现目前的需求,可如果当流程改了呢？我请假超过3天，告诉leader和总经理签字就可以，那你又得一步一步修改程序。如果if语句的条数发生变化的话我们还必须在代码中添加必要的if判断，这对于程序的维护来说是相当麻烦的.如果我们使用职责链模式的话就可以相当简单了.

这个例子就是个list。也是个不纯的职责链，因为每个对象可能处理一部分后，就需要传给下个对象来处理

在工作中，尤其是java web开发中，有两个地方明显使用责任链模式，一个是filter，一个是listener，filter的自定义在web开发中可以对web请求做各种处理和过滤，包括：对请求和相应的字符集处理、对跨站脚本攻击的过滤、获取客户端真实ip地址、获取客户证书、防止盗链等等，在此处，简单模拟责任链模式对请求的处理。