熟悉数据结构的可以想象一下链表的结构，每一个节点都有一个指向后继节点的引用。责任链模式在我们的日常生活中也很常见，比如常见的报销或者请假流程，客户端只需要将请求提交到链上，就不用关心是哪个具体处理对象处理了请求。也可以动态的增加链上的具体处理角色，只要指定后继者处理对象就好。
适用场景
一个请求的处理需要多个对象当中的一个或者几个协作处理，具体哪个对象处理该请求由运行时刻自动确定。
在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
可动态指定一组对象处理请求。
责任链模式优点
将请求的发送者和接收者解耦。
简化了对象。使得对象不需要知道链的结构。
通过改变责任链内的对象或者调动责任链的顺序，允许动态增加或者删除责任链对象。
在系统中增加一个新的具体请求处理者时无须修改原有系统的代码，只需要在客户端重新建链即可，从这一点来看是符合“开闭原则”的。
责任链模式缺点
责任链在处理请求时，可能会耗时过长。
责任链较长时，对象可能会涉及多个，从而影响系统运行性能，消耗内存。
并不保证请求一定会被执行，如果指定后继处理者不当，可能会造成死循环。
纯的与不纯的责任链模式
一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又把责任向下传的情况。
在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收。
纯的责任链模式的实际例子很难找到，一般看到的例子均是不纯的责任链模式的实现。
责任链模式就讲解到这，其实很简单很好理解。难以理解的是其实老李到现在还没有处理好他的工伤赔偿事宜，不知道何时，农民工才能真正受到这个社会的尊重，不知道何时，我们才能骄傲的说我们是一个法治社会。让所有人有法可依，有理可证，有平等和公平可言。
如果可以更好，请给我光明。
如果不能更好，希望别太坏。
认识我的或者关注【码之初】有一段时间的朋友都知道，我是个与世无争的完全自己打理的小号主，能力一般，技术有限，坚持更新，只因热爱。没有精力和财力推广，所以也不曾盈利过，但因为同样的热爱，我们在此相遇，为了感恩这份相遇，我决定，从2020年7月1日开始，每半个月查一下后台数据，阅读最多的前三名，每人一个茶叶蛋，分享文章的前三名，依次为红牛、脉动、农夫山泉，每个月1号、16号公布结果并折现发给这些陪伴码之初的朋友，经济萧条，金额较小，承蒙不弃，皆为心意。