项目做完了，作为老大的你决定叫上项目组的人一起聚个餐犒劳下大家，于是你去财务申请聚餐费用，财务告诉你聚餐费用申请的流程如下：
- 小于500元，项目经理可以审批
- 大于500小于1000，需要部门经理审批
- 大于1000的都需要总经理审批
如果让你来实现这个流程，该如何做呢？常规做法很简单，如下所示：
#import "feeRequest.h"
@implementation feeRequest
-(void)applayForFee:(NSInteger)fee{
if (fee < 500){
[self projectHandle];
}else if(fee < 1000 && fee > 500){
[self depManagerHandle];
}else{
[self generalManagerHandle];
}
}
-(void)projectHandle{
NSLog(@"项目经理同意了费用申请");
}
-(void)depManagerHandle{
NSLog(@"部门经理同意了费用申请");
}
-(void)generalManagerHandle{
NSLog(@"总经理同意了费用申请");
}
@end
实现起来很简单吧。但是仔细分析下，上面的写法有如下两个问题
申请费用的流程可能会经常变动。现在是项目经理-->部门经理--->总经理，如果哪天流程倒过来呢？或者加入了新的审批的人呢？上面的代码就无可避免的需要更改
各个审批流程可能会更改。现在的三个审批流程如上所示，但是可能每个经理的审批的金额会有所更改，这个时候也需要更改上面的代码
抽象下上面的流程：客户提出一个请求（申请聚餐费用），会有很多对象（经理）来处理这个请求，每个对象的处理逻辑是不同的，如果对象自己可以处理这个请求，就会处理完成然后把结果返回给客户，如果自己不能处理，就交给其他对象处理。而且希望上面的流程可以灵活变动，处理请求的对象可以随意组合替换，来适应新的业务需求。
要实现上述功能，可以使用职责链模式，下面就来具体看看
定义
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这 些对象连成一条链,并沿着这条链传递该请求，直到有一个对象处理它为止。
分析下上面的业务场景，客户端提取申请费用的请求，然后项目经理、部门经理、总经理依次处理这个请求，他们组成了一个请求处理链（项目经理-->部门经理--->总经理），客户请求在这个链中传递，直到一个对象处理了这个请求才结束，否则一直向下传递到链的末尾，这正是职责链的功能。
要想让流程的处理灵活多变，可以随意组合和替换，就需要动态构建流程处理的步骤，每个步骤实现一个功能，然后把这些步骤串联起来实现完整的请求处理链。
我们要实现发送者和接受者解耦，那么就需要让提交帮助请求的对象不需要知道谁是最终提供帮助的对象。职责链模式给多个对象处理一个请求的机会,从而解耦发送者和接受者。该请 求沿对象链传递直至其中一个对象处理它，从第一个对象开始,链中收到请求的对象要么亲自处理它,要么转发给链中的下一个候 选者。提交请求的对象并不明确地知道哪一个对象将会处理它，但是最终会有一个隐式对象来保证请求一定会被处理。
由上述分析可知，职责链模式适用于如下几种情况：
- 有多个的对象可以处理一个请求，但是具体是哪个对象处理该请求则是在运行时刻才确定。
- 想在不明确指定接收者的情况下，向多个对象中的一个提交请求。
- 一个请求的处理链可以动态设置
UML结构图及说明
代码实现
1、定义抽象类handler
#import <Foundation/Foundation.h>
@interface handler : NSObject
@property(strong,nonatomic)handler *successor;
-(void)handleRequest:(NSInteger)fee;
@end
==================
#import "handler.h"
@implementation handler
-(void)handleRequest:(NSInteger)fee{
}
@end
2、实现三个具体的职责链成员
#import "handler.h"
@interface projectManagerHandler : handler
@end
=============================
#import "projectManagerHandler.h"
@implementation projectManagerHandler
-(void)handleRequest:(NSInteger)fee{
if (fee < 500) {
NSLog(@"项目经理同意了费用申请");
}else{
if (self.successor)
NSLog(@"项目经理没有权限批准，转到部门经理处理");
[self.successor handleRequest:fee];
}
}
@end
#import "handler.h"
@interface depManagerHandler : handler
@end
=====================
#import "depManagerHandler.h"
@implementation depManagerHandler
-(void)handleRequest:(NSInteger)fee{
if (fee > 500 && fee < 1000) {
NSLog(@"部门经理同意了费用申请");
}else{
if (self.successor)
NSLog(@"部门经理没有权限批准，转到总经理处理");
[self.successor handleRequest:fee];
}
}
@end
#import "handler.h"
@interface generalManagerHandler : handler
@end
=====================
#import "generalManagerHandler.h"
@implementation generalManagerHandler
-(void)handleRequest:(NSInteger)fee{
NSLog(@"总经理同意了费用申请");
}
@end
3、测试
handler *handler1 = [projectManagerHandler new];
handler *handler2 = [depManagerHandler new];
handler *handler3 = [generalManagerHandler new];
//设置责任链中的下一个处理对象
handler1.successor = handler2;
handler2.successor = handler3;
[handler1 handleRequest:100];
NSLog(@"----------------------------------");
[handler1 handleRequest:700];
NSLog(@"----------------------------------");
[handler1 handleRequest:10000];
4、输出
2016-12-14 19:48:37.405 责任链模式[65533:2201187] 项目经理同意了费用申请
2016-12-14 19:48:37.406 责任链模式[65533:2201187] ----------------------------------
2016-12-14 19:48:37.406 责任链模式[65533:2201187] 项目经理没有权限批准，转到部门经理处理
2016-12-14 19:48:37.406 责任链模式[65533:2201187] 部门经理同意了费用申请
2016-12-14 19:48:37.406 责任链模式[65533:2201187] ----------------------------------
2016-12-14 19:48:37.406 责任链模式[65533:2201187] 项目经理没有权限批准，转到部门经理处理
2016-12-14 19:48:37.406 责任链模式[65533:2201187] 部门经理没有权限批准，转到总经理处理
2016-12-14 19:48:37.406 责任链模式[65533:2201187] 总经理同意了费用申请
Program ended with exit code: 0
假设这个时候申请流程变了，如下所示：
- 费用小于1000，由项目经理审批
- 费用大于1000，由总经理审批
流程里面去掉了部门经理，并且每个经理的审批金额也变了，那么如何更改呢？
很简单，分为两步
- 更改原来项目经理和总经理的审批流程
- 改变责任链，如下所示
handler1.successor = handler2;
handler2.successor = handler3;
改为：
handler1.successor = handler3;
客户端计算奖金的方式依然不变，这就是责任链的强大之处，可以动态选择构成责任链的成员，看到这里是不是觉得和装饰者模式很类似？装饰器模式也可以动态的选择给原有对象添加各种功能，他们在某种程度上是可以互相替换的，两者都可以实现动态给对象添加功能。
标准的职责链模式是链中有一个对象能处理请求，就停止把请求往下传递，如果不停止传递，那么此时的职责链模式就和装饰器模式很类似了，每个处理对象都相当于一个装饰器。但是他们的目的值不同的，装饰器是为了透明的给对象添加功能，而职责链是为了解耦请求的发送者和接受者
优缺点
-
降低耦合度
该模式使得一个对象无需知道是其他哪一个对象处理其请求。对象仅需
知道该请求会被“正确”地处理。接收者和发送者都没有对方的明确的信息，且链中的对象不需知道链的结构。
结果是，职责链可简化对象的相互连接。它们仅需保持一个指向其后继者的引用,而不需保持它所有的候选接受者的引用。
-
动态组合职责
当 在 对 象 中 分 派 职 责 时 , 职 责 链 给 你 更多的灵活性。你可以通过在运行时刻对该链进行动态的增加或修改，来增加或改变处理一个请求的职责链对象。
-
不保证被接受
既然一个请求没有明确的接收者,那么就不能保证它一定会被处理。 该请求可能一直到链的末端都得不到处理。一个请求也可能因该链没有被正确配置而得不到处理。
处理多个请求的职责链
上面的职责链中的每个对象（各个经理）都只处理一种请求，实际情况每个对象可能需要处理多种业务类型。比如现在又增加了差旅费用申请。
常规做法是在抽象类handler中增加一个新的方法，然后在每个具体职责链对象中去实现这个方法，但是这样做就违反了开闭原则，导致每次增加或者修改业务，都需要修改职责链中的每个对象。有没有一种通用的处理办法来处理所有的业务呢？肯定有，具体见demo，这里就不展开说了。
功能链
其实在实际开发中一般都会对职责链进行变通使用，标准的职责链实现是：如果链中对象可以处理请求，就停止把请求传递到下一个对象。变通的处理就是不停止传递，每个对象都参与处理请求，这样的例子很多。
比如各种web过滤器，一个连接请求进来，会进行权限检查，字符集转换等过滤，可以被每个过滤功能都实现为一个职责链对象，然后对于不同的请求就可以动态组合这些职责链对象来构成一条职责链进行过滤。
再比如用户的注册流程一般如下图所示：
蓝色方块代表的是一个个的流程，每个箭头流向都是一条链，我们可以把每个流程时限为职责链对象，然后根据不同的流程组合出来不同的职责链来处理注册。
这里只是做抛砖引玉之用，具体代码就不演示了。职责链在实际开发过程中用途广泛，只要是流程类的过程都可以尝试使用职责链去实现。
