设计模式-责任链模式
作为一个上班族，我们可能会经常听到“管理流程混乱”，“职责边界不清晰”等这样或那样的抱怨，这是当组织或系统发展壮大后，一件事由一个人或者一个部门无法独立完成时，不得不面对的问题。就拿平时请假来说，试想如果是一个只有几个人的小公司，很可能连请假条都不用写，直接跟老板说一下就ok了，但是如果公司有一定规模，做为一个小小的螺丝钉，就未必有资格面见老板了，这时就不得不走审批流程了。我们都知道，通常情况下请假需要在oa上写请假单交由各级领导审批，不同级别的领导有权审批的天数不同，例如不超过1天的请假直接领导（tl）审批就可以了，而大于1天不超过3天就需要整个项目的负责人（pm）审批才可以，当然时间更长的，如7天，则可能需要交由cto甚至更高级的领导审批。
这个例子就已经体现出责任的划分了，我们先用代码模拟一下这个请假场景，然后由此引出我们这次的主角---责任链模式。
示例
既然是请假，当然先得有请假单，而请假单又由申请和审批结果两部分组成，分别由请假人和审批领导填写，这不难理解，代码如下：
public class leavecontext
{
/// <summary>
/// 申请
/// </summary>
public leaverequest request { get; set; }
/// <summary>
/// 审批结果
/// </summary>
public leaveresponse response { get; set; }
}
然后再来几个领导，每个领导都有在一定范围内处理请求的能力。经过前面那么多设计模式的熏陶，针对不同级别的领导抽象个管理者基类不难想到吧？
public abstract class manager
{
public string name { get; set; }
public manager(string name)
{
name = name;
}
public abstract void handlerequest(leavecontext context);
}
/// <summary>
/// 团队领导者
/// </summary>
public class tl : manager
{
public tl(string name)
: base(name)
{
}
public override void handlerequest(leavecontext context)
{
if (context.request.leavedays <= 1)
{
context.response = new leaveresponse
{
approver = "tl:" + name,
isagreed = true
};
}
}
}
/// <summary>
/// 项目经理
/// </summary>
public class pm : manager
{
public pm(string name)
: base(name)
{
}
public override void handlerequest(leavecontext context)
{
if (context.request.leavedays > 1
&& context.request.leavedays <= 3)
{
context.response = new leaveresponse
{
approver = "pm:" + name,
isagreed = true
};
}
}
}
/// <summary>
/// 首席技术官
/// </summary>
public class cto : manager
{
public cto(string name)
: base(name)
{
}
public override void handlerequest(leavecontext context)
{
if (context.request.leavedays > 3
&& context.request.leavedays <= 7)
{
context.response = new leaveresponse
{
approver = "cto:" + name,
isagreed = true
};
}
}
}
每个领导都能对同一个请求进行处理，但是也各司其职，只做自己能力范围内的事，并且处理请求的角度和方式也大不相同（即代码实现上有较大的差异，这个例子过于简单，所以这点体现并不明显）。
再来看看调用的地方：
static void main(string[] args)
{
leavecontext context = new leavecontext
{
request = new leaverequest
{
applicant = "张三",
reason = "世界那么大，我想去看看",
leavedays = new random().next(1, 10)
}
};
tl tl = new tl("李四");
pm pm = new pm("王五");
cto cto = new cto("赵六");
if (context.request.leavedays <= 1)
{
tl.handlerequest(context);
}
else if (context.request.leavedays <= 3)
{
pm.handlerequest(context);
}
else if (context.request.leavedays <= 7)
{
cto.handlerequest(context);
}
if (context.response == null)
{
console.writeline($"{context.request.leavedays}天假期太长，没人处理请假申请,请假失败");
}
else
{
console.writeline($"{context.response.approver}审批了{context.request.applicant}的{context.request.leavedays}天请假申请");
}
}
上述代码有点多，但基本思路就是实例化请假单和若干领导对象，然后根据请假天数判断交给哪个领导处理，最后再将处理结果打印输出。有兴趣的话，不妨下载源码，多运行几次看看结果，逻辑还是相当严谨的。
状态模式改造
不过，逻辑虽然严谨，但作为一名优雅的程序员，我们不难挑出一些毛病，一方面，if...else太多，扩展性不好；另一方面，请假难度太大了，还容易出错，实际上，请假者只是想请个假而已，他也不知道谁有权处理，请个假总感觉领导在相互甩锅，管理可不就混乱了吗？
不过对于这两个问题，我们略微思索就会发现，前面遇到过，没错，就是状态模式，只不过状态模式是调用者不想关注系统内部状态的变化，而这里是不想关注内部审批流程的变化。状态模式的解决思路是将状态的设置转移到系统内部，即在一个具体状态类中处理完成对应的业务逻辑之后，设置下一个状态，这里不妨效仿一下。
public class tl : manager
{
public tl(string name)
: base(name)
{
}
public override void handlerequest(leavecontext context)
{
if (context.request.leavedays <= 1)
{
context.response = new leaveresponse
{
approver = "tl:" + name,
isagreed = true
};
return;
}
pm pm = new pm("王五");
pm.handlerequest(context);
}
}
其他几个管理者对象类似处理，这样一来，调用者就简单了，代码如下：
static void main(string[] args)
{
...
tl tl = new tl("李四");
tl.handlerequest(context);
...
}
不过，调用者虽然简单了，但是把锅甩给了管理者，不妨再看看上面的tl类，不难看出面向实现编程了，违背了迪米特原则，进而也就违背了开闭原则，记得在状态模式中也同样有这个问题，我们当时是通过享元模式解决的，原因是状态是可以共享的，并且状态是系统内部的，外部不应该知道的。而这里情况有所不同，管理者对象是不可以共享的，外部也是可以访问的，因此，处理手段也就不同了。我们在manager基类中添加nextmanager属性，这也是一种依赖注入的手段，之前的设计模式我们用过了方法注入，构造函数注入，这是第三种注入方式---属性注入。
public abstract class manager
{
public manager nextmanager { get; set; }
...
}
然后具体的实现类中，通过nextmanager指向下一个管理者。下面以tl类为例：
public class tl : manager
{
...
public override void handlerequest(leavecontext context)
{
if (context.request.leavedays <= 1)
{
context.response = new leaveresponse
{
approver = "tl:" + name,
isagreed = true
};
return;
}
nextmanager?.handlerequest(context);
}
}
这样所有管理者类就又面向抽象编程，可以轻松扩展了。我们再来看看如何调用：
static void main(string[] args)
{
...
tl tl = new tl("李四");
pm pm = new pm("王五");
cto cto = new cto("赵六");
tl.nextmanager = pm;
pm.nextmanager = cto;
tl.handlerequest(context);
...
}
乍一看，心里拔凉拔凉的，又变复杂了，好不容易甩出去的锅又被甩回来了。不过呢，虽然有瑕疵，但相对于最开始的实现，还是好了很多，至少，请假时只需要找直接领导就可以了，审批细节也不用再关注了，这就是责任链模式，下面看一下类图。
示例类图
定义
多个对象都有机会处理某个请求，将这些对象连成一条链，并沿着这条链传递该请求，直到处理完成为止。责任链模式的核心就是“链”，是由多个处理者串起来组成。
类图
- handler：抽象处理者角色，是一个处理请求的接口或抽象类；
- concretehandler：具体的处理者角色，具体的处理者接收到请求后可以选择将请求处理掉，或者将请求传递给下一个处理者。
责任链模式+模板方法模式
通过前面的代码和定义，我们可以看到，责任链模式其实并不完善，首先管理者子类实现中有逻辑和代码上的重复，例如都需要判断是否有权力处理请求，处理完之后都需要交给下一个处理者处理，并且这个流程是固定的。因此，我们可以进行如下改造，把公共固定的部分提取到基类中：
public abstract class manager
{
public manager nextmanager { get; set; }
public string name { get; set; }
public manager(string name)
{
name = name;
}
public void handlerequest(leavecontext context)
{
if (canhandle(context))
{
handle(context);
return;
}
nextmanager?.handlerequest(context);
}
protected abstract bool canhandle(leavecontext context);
protected abstract void handle(leavecontext context);
}
上述代码将算法骨架封装到了handlerequest(leavecontext context)方法中，然后将算法子步骤canhandle(leavecontext context)和handle(leavecontext context延时到子类中实现，当然，由于子步骤不应该被外部直接调用，因此访问修饰符为protected，看到了吗？这是标准的模板方法模式。
再来看看具体子类如何实现，还是以tl为例：
public class tl : manager
{
public tl(string name)
: base(name)
{
}
protected override bool canhandle(leavecontext context)
{
return context.request.leavedays <= 1;
}
protected override void handle(leavecontext context)
{
context.response = new leaveresponse
{
approver = "tl:" + name,
isagreed = true
};
}
}
子类更加干净清爽，职责也更加单一了，只需关心自己的处理逻辑，甚至都不用关心做完之后该交给谁，扩展起来更加容易了。
责任链模式+建造者模式
除此之外，另外一个问题其实更加明显，就是前面说的锅甩来甩去还是回到了调用者身上，虽说调用者不再需要知道每个领导的审批权限范围，但是除了指定自己的领导，还得指定领导的领导，领导的领导的领导，这其实也不合理，出现这个问题的原因是什么呢？原因是不符合常理，我们忽略的一个很重要的部门---人力行政部（hr），请假流程应该是他们提前制定好的，而不是每次请假时临时制定的。
因此，要解决这个问题，首先得加入一个hr类，用于管理请假审批流程：
public class hr
{
public manager getmanager()
{
tl tl = new tl("李四");
pm pm = new pm("王五");
cto cto = new cto("赵六");
tl.nextmanager = pm;
pm.nextmanager = cto;
return tl;
}
}
然后，再看看调用的地方：
static void main(string[] args)
{
...
hr hr = new hr();
manager manager = hr.getmanager();
manager.handlerequest(context);
...
}
又变得简单了，并且也更合理了。不过整体上还是有点自欺欺人，因为新的hr类又面向实现编程，变得难以维护了，因此，还得改进，改进方法还是老套路，面向抽象编程，然后通过集合管理多个实例，具体代码如下：
public class hr
{
private list<manager> _managers = new list<manager>();
public void addmanager(manager manager)
{
_managers.add(manager);
}
public manager getmanager()
{
manager currentmanager = null;
for (int i = _managers.count - 1; i >= 0; i--)
{
if (currentmanager != null)
{
_managers[i].nextmanager = currentmanager;
}
currentmanager = _managers[i];
}
return currentmanager;
}
}
这里直接一步到位了，但是应该能看懂，不过，大家有没有看出这是建造者模式呢？没看出也没关系，我们后面会再改进一次，毕竟hr没面向抽象编程，光秃秃的看着也不舒服。但在此之前，我们先看看调用的地方：
static void main(string[] args)
{
...
hr hr = new hr();
hr.addmanager(new tl("李四"));
hr.addmanager(new pm("王五"));
hr.addmanager(new cto("赵六"));
manager manager = hr.getmanager();
manager.handlerequest(context);
...
}
看到这里的朋友怕是要开骂了，这到底是想干啥，封装来封装去，来来回回好几次，最后还是回到了原点。但事实上，已经有了很大的不同，第一次，调用者对业务逻辑有了较深的耦合，例如调用者必须知道每个领导的审批权力；第二次，耦合度降低了，但还是需要知道调用链的关系，而第三次，也就是这一次，其它的都不用知道，只需要创建对象就可以了，而创建对象是无论如何都绕不开的。并且，我们经过一次次的改进，看似还是回到了原点，但实际上已经将变化一步步从程序内部抛到了程序的最外层，可以通过依赖注入进一步解耦了，我们不妨换成asp.net core应用程序看看，同时我们再进行最后一次改造:
public interface imanagerbuilder
{
void addmanager(manager manager);
manager build();
}
public class managerbuilder: imanagerbuilder
{
private readonly list<manager> _managers = new list<manager>();
public void addmanager(manager manager)
{
_managers.add(manager);
}
public manager build()
{
...
}
}
其实这次改造并没有实质性的变化，仅仅是换了个名字并且加了个抽象的接口而已，目的是为了方便看出它确实是建造者模式。重点是如何使用它，先添加如下针对iservicecollection的扩展方法。
public static class managerservicecollectionextensions
{
public static imanagerbuilder addmanagers(this iservicecollection services)
{
imanagerbuilder managerbuilder = new managerbuilder();
managerbuilder.addmanager(new tl("李四"));
managerbuilder.addmanager(new pm("王五"));
managerbuilder.addmanager(new cto("赵六"));
services.addsingleton(managerbuilder);
return managerbuilder;
}
}
然后在startup中调用，代码如下所示：
public void configureservices(iservicecollection services)
{
services.addcontrollers();
services.addmanagers();
}
好了，就是这么简单，接下来就可以在项目的任何地方通过依赖注入的方式使用了，当然，addmanagers(this iservicecollection services)还有瑕疵，但是，这可以通过配置文件或者读取数据库的方式解决，这里就不再继续深入下去了。
优缺点
优点
责任链模式最大的优点就是将请求和处理分离，请求者可以不用知道是谁处理的，处理者也可以不用知道请求的全貌，两者解耦，提高系统的灵活性。
缺点
性能不高
既然责任链模式的核心是“链”，就说明每次请求都需要遍历整个链条，这必然会带来较大的性能损耗，不过事实上，责任链模式并非必须使用链条，我们知道数据结构中有数组和链表两种结构，而我们前面刚学过的观察模式就和责任链模式就有类似的关系，观察者模式中通过集合保存所有的观察者，然后遍历集合，责任链模式也可以采用相同的手段，不过责任链模式采用集合保存所有处理者之后，或许就变成观察者模式了，但是这重要吗？
调试不方便
责任链模式采用了类似递归的方式，调试的时候逻辑可能比较复杂。
总结
责任链模式通常可以用在含有流程的业务中，如工作流，流水线，请求流等，当然也可以将一个大的功能块切分成若干小块，然后通过责任链模式串联起来，责任链模式常见于各种框架中，是代码重构的利器，不过由于其性能不高，逻辑相对复杂，并且如果责任划分不清，很容易产生误用，带来的可能是灾难，因此也需要慎重使用。况且，能通过责任链模式实现的场景往往也可以通过其它模式代替，如策略模式，状态模式，观察者模式等。另外，责任链模式的每个处理者也可以只处理请求的一部分，asp.net core中的中间件就是典型例子，还有前面请假的例子，在有些公司，不管请多少天假，可能都需要所有领导逐级审批，所有领导都同意才算通过，只要有一个不同意就不通过，这依然是责任链模式。
责任链模式使用起来可以非常灵活，实现方式也不止一种，但很少单独使用，更多时候还需要搭配其他模式一起使用，因此，要用好责任链模式也别忘了复习其它设计模式哦！