定义：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
类型：行为类模式
类图：
首先来看一段代码：
我要评论
public void test(int i, request request){
if(i==1){
handler1.response(request);
}else if(i == 2){
handler2.response(request);
}else if(i == 3){
handler3.response(request);
}else if(i == 4){
handler4.response(request);
}else{
handler5.response(request);
}
}
代码的业务逻辑是这样的，方法有两个参数：整数i和一个请求request，根据i的值来决定由谁来处理request，如果i==1，由handler1来处理，如果i==2，由handler2来处理，以此类推。在编程中，这种处理业务的方法非常常见，所有处理请求的类有if…else…条件判断语句连成一条责任链来对请求进行处理，相信大家都经常用到。这种方法的优点是非常直观，简单明了，并且比较容易维护，但是这种方法也存在着几个比较令人头疼的问题：
代码臃肿：实际应用中的判定条件通常不是这么简单地判断是否为1或者是否为2，也许需要复杂的计算，也许需要查询数据库等等，这就会有很多额外的代码，如果判断条件再比较多，那么这个if…else…语句基本上就没法看了。
耦合度高：如果我们想继续添加处理请求的类，那么就要继续添加else if判定条件；另外，这个条件判定的顺序也是写死的，如果想改变顺序，那么也只能修改这个条件语句。
既然缺点我们已经清楚了，就要想办法来解决。这个场景的业务逻辑很简单：如果满足条件1，则由handler1来处理，不满足则向下传递；如果满足条件2，则由handler2来处理，不满足则继续向下传递，以此类推，直到条件结束。其实改进的方法也很简单，就是把判定条件的部分放到处理类中，这就是责任连模式的原理。
责任连模式的结构
责任连模式的类图非常简单，它由一个抽象地处理类和它的一组实现类组成：
抽象处理类：抽象处理类中主要包含一个指向下一处理类的成员变量nexthandler和一个处理请求的方法handrequest，handrequest方法的主要主要思想是，如果满足处理的条件，则有本处理类来进行处理，否则由nexthandler来处理。
具体处理类：具体处理类主要是对具体的处理逻辑和处理的适用条件进行实现。
实例
责任链模式有两个角色：
抽象处理者（handler）角色 ：定义一个请求的接口。如果需要可以定义个一个方法用来设定和返回下家对象的引用。
具体处理者（concretehandler）角色 ：如果可以处理就处理请求，如果不能处理，就把请求传给下家，让下家处理。也就是说它处理自己能处理的请求且可以访问它的下家。
上述模式的测试代码如下：
package chainofresp;
/**
*描述：抽象处理角色
*/
public abstract class handler {
protected handler successor;
/**
*描述：处理方法
*/
public abstract void handlerrequest(string condition);
public handler getsuccessor() {
return successor;
}
public void setsuccessor(handler successor) {
this.successor = successor;
}
}
package chainofresp;
/**
*描述：具体处理角色
*/
public class concretehandler1 extends handler {
@override
public void handlerrequest(string condition) {
// 如果是自己的责任，就自己处理，负责传给下家处理
if(condition.equals("concretehandler1")){
system.out.println( "concretehandler1 handled ");
return ;
}else{
system.out.println( "concretehandler1 passed ");
getsuccessor().handlerrequest(condition);
}
}
}
package chainofresp;
/**
*描述：具体处理角色
*/
public class concretehandler2 extends handler {
@override
public void handlerrequest(string condition) {
// 如果是自己的责任，就自己处理，负责传给下家处理
if(condition.equals("concretehandler2")){
system.out.println( "concretehandler2 handled ");
return ;
}else{
system.out.println( "concretehandler2 passed ");
getsuccessor().handlerrequest(condition);
}
}
}
package chainofresp;
/**
*描述：具体处理角色
*/
public class concretehandlern extends handler {
/**
* 这里假设n是链的最后一个节点必须处理掉
* 在实际情况下，可能出现环，或者是树形，
* 这里并不一定是最后一个节点。
*
*/
@override
public void handlerrequest(string condition) {
system.out.println( "concretehandlern handled");
}
}
package chainofresp;
/**
*描述：测试类
*/
public class client {
/**
*描述：
*/
public static void main(string[] args) {
handler handler1 = new concretehandler1();
handler handler2 = new concretehandler2();
handler handlern = new concretehandlern();
//链起来
handler1.setsuccessor(handler2);
handler2.setsuccessor(handlern);
//假设这个请求是concretehandler2的责任
handler1.handlerrequest("concretehandler2");
}
}
举这样一个例子，在玩具工厂的生产车间，流水线就是一条责任链，假如一个玩具飞机有外壳装配员，引擎装配员，螺旋桨装配员，模型包装员组成。当这个物件飞机流到谁那里，谁就负责安装他负责的这一部分，这部分安装完成后流到下一个环节，知道所有环境完成。这个是一生成的责任链。还有一个质量检测链，质量检测也分多部，外壳检测，引擎检测，螺旋桨检测，包装检测。当产品留到检测员那里检测自己负责的那一块，如果有问题直接拎出来，如果没问题则传给下一个检测员，直到所有检测完成。这两个都是责任链，但是区别是，生成责任链每个人都会处理，并处理一部分；而质量检测责任链经过判断，要么处理掉，要么不处理流下去。这就是责任链的两种分类，后一种叫做纯的责任链，前一种叫做不纯的责任链，纯的责任链在实际应用中很少存在，常见的为不纯的责任链，上面的模型是模拟纯的责任链来处理的。
责任链模式的优缺点
责任链模式与if…else…相比，他的耦合性要低一些，因为它把条件判定都分散到了各个处理类中，并且这些处理类的优先处理顺序可以随意设定。责任链模式也有缺点，这与if…else…语句的缺点是一样的，那就是在找到正确的处理类之前，所有的判定条件都要被执行一遍，当责任链比较长时，性能问题比较严重。
责任链模式的适用场景
就像开始的例子那样，假如使用if…else…语句来组织一个责任链时感到力不从心，代码看上去很糟糕时，就可以使用责任链模式来进行重构。
总结
责任链模式其实就是一个灵活版的if…else…语句，它就是将这些判定条件的语句放到了各个处理类中，这样做的优点是比较灵活了，但同样也带来了风险，比如设置处理类前后关系时，一定要特别仔细，搞对处理类前后逻辑的条件判断关系，并且注意不要在链中出现循环引用的问题。
如对本文有疑问， 点击进行留言回复！！
![[杭电多校2020]第一场 1004 Distinct Sub-palindromes](http://www.lhsxpumps.com/_images5/10qianwan/20200724/s_0_202007241733388592.png)
[杭电多校2020]第一场 1004 Distinct Sub-palindromes
Swift -- 将本地生成的UIImage进行持久化保存（存到文件中fileManager.createFile）
网友评论