介绍：
责任链模式属于行为型设计模式。它的定义为：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，只到有对象处理它为止。
类图：
Handler（抽象处理者角色）：声明一个请求处理方法，并在其中保持一个对下一个处理节点Hanlder对象的引用。
ConcreteHandler（具体处理者角色）：对请求进行处理，如果不能处理则将请求转发给下一个节点上的处理对象。
用法：
• 多个对象可以处理同一请求，但具体由哪个对象处理则在运行时动态决定
• 在请求处理者不明确的情况下向多个对象中的一个提交一个请求
• 需要动态指定一组对象处理请求
个人理解：
此模式的核心就是转移责任，首先是将多个对象组成一条链，然后请求过来时就按顺序找出相应负责的对象是哪一个，谁消费了请求，就停止请求。
例子：
在很多生活中的例子，例如派快递由不同区域的快递员负责处理快件，不属于他配送范围的快件则转移给下一个快递员处理；公司OA中的审批流程，请假的时候需要直属领导审批，再到部门领导审批等。
在Android中，每当用户触碰屏幕时，都会将对应的事件包装成一个事件对象从ViewTree的顶部至上而下地分发传递，View的事件分发机制是责任链模式的经典应用，此部分内容比较深，有兴趣深入理解可以查看其他资料哈。
设计OA审批系统
设计思路：
OA的审批流程首先是普通员工（Woker）向直属上司（Leader）提出请假申请，3天以内的请假直属上司（Leader）可以进行审批；3天以外的请假则需要直属上司(Leader)同意后再由技术总监（CTO）审批。
1、创建一条请求
public class LeaveRequest {
private String name; //请假人
private int days; //请假天数
private String reason; //请假事由
private String approveStr = "待审批";
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getDays() {
return days;
}
public void setDays(int days) {
this.days = days;
}
public String getReason() {
return reason;
}
public void setReason(String reason) {
this.reason = reason;
}
public String getApproveStr() {
return approveStr;
}
public void setApproveStr(String approveStr) {
this.approveStr = approveStr;
}
public String toString() {
return "【" + name + "】请假" + days + "天，原因：" + reason + "，审批结果：" + approveStr;
}
}
这是一条请假请求，每个节点的对象都机会处理这个请求，例如TeamLeader角色和CTO角色。
2、创建Handler角色
public abstract class Employee {
protected Employee leader;
public abstract void handleRequest(LeaveRequest request);
}
Employee类是员工基类，定义了一个对下一个处理节点Hanlder对象的引用和处理流程的方法。
3、创建ConcreteHandler角色
程序员：自己无权处理请假流程
public class Coder extends Employee {
@Override
public void handleRequest(LeaveRequest request) {
//自己无权处理
leader.handleRequest(request);
}
}
小组长：可以处理三天以内的请假
public class TeamLeader extends Employee {
@Override
public void handleRequest(LeaveRequest request) {
if (request.getDays() <= 3){
//组长同意了
request.setApproveStr("小组长同意了");
} else {
leader.handleRequest(request);
}
}
}
大领导：看心情批假
public class CTO extends Employee {
private boolean isHappy = false;
public void setIshappy(boolean ishappy) {
this.isHappy = ishappy;
}
@Override
public void handleRequest(LeaveRequest request) {
if (request.getDays() <= 10) {
//批不批主要看心情
if (isHappy) {
request.setApproveStr("大领导同意了");
} else {
request.setApproveStr("大领导不同意，请假太多了！");
}
}
}
}
4、测试与实现
public class Client {
public static void main(String[] args) {
//1.首先有一条请假流程
LeaveRequest request = new LeaveRequest();
request.setName("小明");
request.setDays(10);
request.setReason("外出办事");
//2.职场食物链的组成：底层员工->小组长->大领导
Coder coder = new Coder();
TeamLeader teamLeader = new TeamLeader();
CTO cto = new CTO();
cto.setIshappy(true);
coder.leader = teamLeader;
teamLeader.leader = cto;
//3.员工发送一个请求
coder.handleRequest(request);
//4.查看请求处理结果
System.out.print(request.toString());
}
}
【小明】请假10天，原因：外出办事，审批结果：大领导同意了
风趣幽默的实例已经展示完毕，整个模式的核心就是转移责任，链中的每个对象都有机会处理请求。例子也比较简单，非常好理解。
总结：
这个模式的好处在于弱化请求方和处理方的关联关系，让双方都可以成为独立复用的组件。缺点也很明显，链上的节点太长的话会影响性能。
另外，此模式也不要一言不合就滥用于替换if-else的代码，因为此模式的设计重点不在于选择逻辑的判断，而是转移责任，即谁负责处理的这一个事件。应用上还是要具体情况具体分析~
感谢您的阅读~
转载请注明出处喔：https://www.jianshu.com/p/9529c58aa80b
推荐阅读
基础篇：
设计模式前篇之——UML类图必会知识点
设计模式前篇之——一起过一下面向对象的概念
创建型模式：
简易理解设计模式之：简单工厂模式——来试试接入支付功能
简易理解设计模式之：工厂方法模式——数据存储例子
简易理解设计模式之：抽象工厂模式——更换数据库例子
简易理解设计模式之：建造者模式——学习使用“链式调用”
简易理解设计模式之：原型模式——深、浅拷贝的概念
简易理解设计模式之：单例模式——单例模式的几种常用写法
结构型模式：
简易理解设计模式之：适配器模式——Android列表视图控件设计方式
简易理解设计模式之：桥接模式——穿衣服经典案例2
简易理解设计模式之：组合模式——实现View中的树状结构
简易理解设计模式之：装饰模式——穿衣服经典案例
简易理解设计模式之：外观模式——第三方SDK的帮助类
简易理解设计模式之：享元模式——五子棋游戏例子
简易理解设计模式之：代理模式——iOS视图控件设计方式
行为型模式：
简易理解设计模式之：策略模式——优化一下支付功能
简易理解设计模式之：模板方法模式——Android中的BaseActivity基类
简易理解设计模式之：观察者模式——监听与回调
简易理解设计模式之：状态模式——优化登录操作
简易理解设计模式之：备忘录模式——Word文档的工作原理
简易理解设计模式之：迭代器模式——遍历对象的好帮手
简易理解设计模式之：命令模式——实现命令的参数化配置
简易理解设计模式之：责任链模式——OA中请假流程示例
简易理解设计模式之：中介者模式——多人聊天室例子
简易理解设计模式之：解释器模式——语言和文法
简易理解设计模式之：访问者模式——员工考核例子