Android设计模式之责任链模式

之前计划先把设计模式学完，但是感觉设计模式毕竟这么多种，粗略过一遍又不太好，所以决定还是先学自己需要学的Android知识点，在学习的过程中遇到了哪种设计模式再来学习，感觉这样效率会高一点，而且更容易自己理解。昨天在研究Android事件分发机制时发现Android事件分发机制是一种典型的责任链模式。于是特意在去学习责任链模式，所以就有了这篇文章，这文章基本都是参照《Android源码设计模式解析与实战》一书。

一、责任链模式的定义

使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

二、责任链模式的使用场景

多个对象可以处理同一请求，但具体由哪个对象处理则在运行时动态决定。
在请求处理者不明确的情况下向多个对象中的一个提交一个请求。
需要动态指定一组对象处理请求。

三、责任链模式UML类图

示意图：

四、责任链模式具体实例

看了这么多概念性的东西总觉得优点懵逼，接下来引用书上的一个例子，感觉特别简单明了。
栗子：小群某天接到通知说要去国外进修学习新技术，小群听到这消息心中暗喜，表面上还是假装很镇定，于是她特意问了一下公司是否报销，在得到了肯定的答案之后小群背上背包踏上了去国外的进修之旅。小群这趟去国外学习一趟花了近10万块，于是小群上班后的第一天就是找公司报销，向组长申请报销费用，组长一看这么大一笔钱，他哪里有这个权限，他手里最多才可以批1000块，于是组长就拿着票据去找部门主管，主管一看要报这么多钱，自己权限内只能批1万以下的费用，这完全超出了自己的权限范围呀，于是又只得去找上一级也就是经理，经理一看，我也只能批5万以下的费用啊。于是二话不说拿着票据直接奔向了老板的办公室，让老板去处理小群的这个请求。上面的这个情景就是一个责任链的小栗子，每一个人，准确的说是每一类人代表这条链上的一个节点，小群是请求的发起者，而老板也就是我们的大BOSS则是处于链条顶端的类，小群从链的底端开始发出一个申请报账的请求，首先由组长处理该请求，组长比对后发现自己权限不够，于是将该请求转发给位于该链中下一个节点的主管，主管比对后发现自己权限也不够，又只能将该请求转发给经理，而经理同样权限不够，毕竟10万块的大数目只有老板能处理，于是最后经理又将请求转发给了老板，这样层层转达直到请求被处理。从中大家可以看到一个显而易见的事，就是至始至终小群只与组长产生了关联，后面具体由谁处理报销的票据，小群并不关心，小群只关心自己的票据（请求）有没有被成功处理。责任链模式在这里很好的将请求的发起者和处理者解耦。接下来我们用代码来实现这一过程。

五、责任链模式代码实现

1. 抽象领导者

/**
 * 抽象的领导类，即UML图中的Hanlder
 */

public abstract class Lea