## 引入 在阎宏博士的《JAVA与模式》一书中开头是这样描述责任链（Chain of Responsibility）模式的： > 责任链模式是一种对象的行为模式。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。 ## 定义 避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止，这就是职责链模式。 在职责链模式中最关键的一点就是客户提交请求后，请求沿着链往下传递直到有一个处理者处理它，在这里客户无需关心它的请求是哪个处理者来处理，反正总有一个处理者会处理它的请求。 在这里客户端和处理者都没有对方明确的信息，同时处理者也不知道职责链中的结构。所以职责链可以简化对象的相互连接，他们只需要保存一个指向其后续者的引用，而不需要保存所有候选者的引用。 在职责链模式中我们可以随时随地的增加或者更改一个处理者，甚至可以更改处理者的顺序，增加了系统的灵活性。处理灵活性是增加了，但是有时候可能会导致一个请求无论如何也得不到处理，它会被放置在链末端，这个既是职责链的优点也是缺点。 ## 结构 　　下面使用了一个责任链模式的最简单的实现。  责任链模式涉及到的角色如下所示： * 抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。上图中Handler类的聚合关系给出了具体子类对下家的引用，抽象方法handleRequest()规范了子类处理请求的操作。 * 具体处理者(ConcreteHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。 ## 代码实现 来考虑这样一个功能:申请聚餐费用的管理。 　　很多公司都是这样的福利，就是项目组或者是部门可以向公司申请一些聚餐费用，用于组织项目组成员或者是部门成员进行聚餐活动。 　　申请聚餐费用的大致流程一般是：由申请人先填写申请单，然后交给领导审批，如果申请批准下来，领导会通知申请人审批通过，然后申请人去财务领取费用，如果没有批准下来，领导会通知申请人审批未通过，此事也就此作罢。 　　不同级别的领导，对于审批的额度是不一样的，比如，项目经理只能审批500元以内的申请；部门经理能审批1000元以内的申请；而总经理可以审核任意额度的申请。 　　也就是说，当某人提出聚餐费用申请的请求后，该请求会经由项目经理、部门经理、总经理之中的某一位领导来进行相应的处理，但是提出申请的人并不知道最终会由谁来处理他的请求，一般申请人是把自己的申请提交给项目经理，或许最后是由总经理来处理他的请求。 　　可以使用责任链模式来实现上述功能：当某人提出聚餐费用申请的请求后，该请求会在 项目经理—〉部门经理—〉总经理 这样一条领导处理链上进行传递，发出请求的人并不知道谁会来处理他的请求，每个领导会根据自己的职责范围，来判断是处理请求还是把请求交给更高级别的领导，只要有领导处理了，传递就结束了。 　　需要把每位领导的处理独立出来，实现成单独的职责处理对象，然后为它们提供一个公共的、抽象的父职责对象，这样就可以在客户端来动态地组合职责链，实现不同的功能要求了。  抽象处理者角色类 ``` public abstract class Handler { /** * 持有下一个处理请求的对象 */ protected Handler successor = null; /** * 取值方法 */ public Handler getSuccessor() { return successor; } /** * 设置下一个处理请求的对象 */ public void setSuccessor(Handler successor) { this.successor = successor; } /** * 处理聚餐费用的申请 * @param user 申请人 * @param fee 申请的钱数 * @return 成功或失败的具体通知 */ public abstract String handleFeeRequest(String user , double fee); } ``` 具体处理者角色 ``` public class ProjectManager extends Handler { @Override public String handleFeeRequest(String user, double fee) { String str = ""; //项目经理权限比较小，只能在500以内 if(fee < 500) { //为了测试，简单点，只同意张三的请求 if("张三".equals(user)) { str = "成功：项目经理同意【" + user + "】的聚餐费用，金额为" + fee + "元"; }else { //其他人一律不同意 str = "失败：项目经理不同意【" + user + "】的聚餐费用，金额为" + fee + "元"; } }else { //超过500，继续传递给级别更高的人处理 if(getSuccessor() != null) { return getSuccessor().handleFeeRequest(user, fee); } } return str; } } ``` ``` public class DeptManager extends Handler { @Override public String handleFeeRequest(String user, double fee) { String str = ""; //部门经理的权限只能在1000以内 if(fee < 1000) { //为了测试，简单点，只同意张三的请求 if("张三".equals(user)) { str = "成功：部门经理同意【" + user + "】的聚餐费用，金额为" + fee + "元"; }else { //其他人一律不同意 str = "失败：部门经理不同意【" + user + "】的聚餐费用，金额为" + fee + "元"; } }else { //超过1000，继续传递给级别更高的人处理 if(getSuccessor() != null) { return getSuccessor().handleFeeRequest(user, fee); } } return str; } } ``` ``` public class GeneralManager extends Handler { @Override public String handleFeeRequest(String user, double fee) { String str = ""; //总经理的权限很大，只要请求到了这里，他都可以处理 if(fee >= 1000) { //为了测试，简单点，只同意张三的请求 if("张三".equals(user)) { str = "成功：总经理同意【" + user + "】的聚餐费用，金额为" + fee + "元"; }else { //其他人一律不同意 str = "失败：总经理不同意【" + user + "】的聚餐费用，金额为" + fee + "元"; } }else { //如果还有后继的处理对象，继续传递 if(getSuccessor() != null) { return getSuccessor().handleFeeRequest(user, fee); } } return str; } } ``` 客户端类 ``` public class Client { public static void main(String[] args) { //先要组装责任链 Handler h1 = new GeneralManager(); Handler h2 = new DeptManager(); Handler h3 = new ProjectManager(); h3.setSuccessor(h2); h2.setSuccessor(h1); //开始测试 String test1 = h3.handleFeeRequest("张三", 300); System.out.println("test1 = " + test1); String test2 = h3.handleFeeRequest("李四", 300); System.out.println("test2 = " + test2); System.out.println("---------------------------------------"); String test3 = h3.handleFeeRequest("张三", 700); System.out.println("test3 = " + test3); String test4 = h3.handleFeeRequest("李四", 700); System.out.println("test4 = " + test4); System.out.println("---------------------------------------"); String test5 = h3.handleFeeRequest("张三", 1500); System.out.println("test5 = " + test5); String test6 = h3.handleFeeRequest("李四", 1500); System.out.println("test6 = " + test6); } } ``` 运行结果如下所示：  ## 纯的与不纯的责任链模式 　　一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又 把责任向下传的情况。 　　在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收。 　　纯的责任链模式的实际例子很难找到，一般看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式，这也许是有道理的。但是在实际的系统里，纯的责任链很难找到。如果坚持责任链不纯便不是责任链模式，那么责任链模式便不会有太大意义了。 ## 优点 * 降低耦合度,客户端不需要知道是谁处理了他的请求,只知道该请求被正确的处理了就可以了 * 可以简化对象的相互连接,一个接收者只需要保存一个后面接收者的引用就可以了,而不是保留所有的接收者的引用 * 增强了给对象指派职责的灵活性,只需要在运行时刻在该链上增加或者修改接收者的引用,就可以调动他们的次序.以及增加或删除接收者 ## 缺点 * 不能保证客户端发出的请求一定会被处理.因为这个请求没有明确的接收者, * 系统性能将受到一定的影响,可能会造成循环调用 ## 适用场景 * 1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。 * 2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 * 3、可动态指定一组对象处理请求。 ## 总结 * 1、职责链模式将请求的发送者和接受者解耦了。客户端不需要知道请求处理者的明确信息，甚至不需要知道链的结构，它只需要将请求进行发送即可。 * 2、职责链模式能够非常方便的动态增加新职责或者删除职责。 * 3、客户端发送的请求可能会得不到处理。 * 4、处理者不需要知道链的结构，只需要明白他的后续者是谁就可以了。这样就简化了系统中的对象。