职责链模式（Chain of Responsibility）
设计模式使用的例子https://github.com/LinkinStars/DesignPatternsAllExample
一、定义
避免将请求发送者与接受者耦合在一起，让多个对象都有机会接受请求，将这些对象连成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
二、结构
Handler（抽象处理者）：定义了一个处理请求的接口，一般设计为抽象类，由于不同的具体处理者处理请求的方式不同，因此在其中定义了抽象请求处理方法。
ConcreteHandler（具体处理者）：它是抽象处理者的子类，可以处理用户请求，它实现了在抽象处理者中定义的抽象请求处理方法。
在处理请求之前需要判断是否有相应的处理权限，如果可以则处理，否则则将请求转发给后继者。
三、优点
使得一个对象无需知道是其他哪一个对象处理其请求，对象仅需知道该请求会被处理即可，且链式结构由客户端创建
在系统中增加一个新的具体处理者无须修改原有系统源代码，只需要在客户端重新建立链式结构即可
四、缺点
由于一个请求没有一个明确地接受者，无法保证它一定会被处理
对于较长的职责链，系统性能有一定影响且不利于调试
如果建立链不当，可能会造成循环调用，导致系统进入死循环
五、应用场景
有多个对象处理同一个请求且无需关心请求的处理对象时谁以及它是如何处理的
可以动态地指定一组对象处理请求，客户端可以动态创建职责链来处理请求，还可以改变链中处理者之间的先后次序
六、个人总结
1、这个设计模式的名字很直观的表现了这个设计模式的特性
当一个请求过来时，我们使用一个链条来处理这个请求
链条上的每一个处理者只是处理自己能处理的请求，而不处理多余的请求
处理不了的就会交个下一个人
2、这个模式的使用非常简单，在下面的情况下使用效果很好
当相同的请求需要不同的处理方式，或者是不同权限的请求需要不同的类来处理
处理请求的内部逻辑非常复杂，或者处理的类型分析比较复杂
处理的次序需要进行改变的，需要解耦复杂处理请求的
3、需要注意的是构建责任链的时候一定要正确
参考博客：http://www.cnblogs.com/edisonchou/p/7215547.html