责任链模式

Published on 2016 - 07 - 14

责任链模式的定义

责任链模式定义如下:

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.Chain the receiving objects and pass the request along the chain until an object handles it.(使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止。)

责任链模式的重点是在“链”上,由一条链去处理相似的请求在链中决定谁来处理这个请求,并返回相应的结果,其通用类图如图4所示。

责任链模式的核心在“链”上,“链”是由多个处理者ConcreteHandler组成的,我们先来看抽象Handler类,如代码清单14所示。

public abstract class Handler {
     private Handler nextHandler;
     //每个处理者都必须对请求做出处理
     public final Response handleMessage(Request request){
             Response response = null;  
             //判断是否是自己的处理级别
             if(this.getHandlerLevel().equals(request.getRequestLevel())){
                    response = this.echo(request);
             }else{  //不属于自己的处理级别
                    //判断是否有下一个处理者
                    if(this.nextHandler != null){
                            response = this.nextHandler.handleMessage(request);
                    }else{
                            //没有适当的处理者,业务自行处理
                    }
             }
             return response;
     }
     //设置下一个处理者是谁
     public void setNext(Handler _handler){
             this.nextHandler = _handler;
     }
     //每个处理者都有一个处理级别
     protected abstract Level getHandlerLevel();
     //每个处理者都必须实现处理任务
     protected abstract Response echo(Request request);
}

抽象的处理者实现三个职责:一是定义一个请求的处理方法handleMessage,唯一对外开放的方法;二是定义一个链的编排方法setNext,设置下一个处理者;三是定义了具体的请求者必须实现的两个方法:定义自己能够处理的级别getHandlerLevel和具体的处理任务echo。

注意 在责任链模式中一个请求发送到链中后,前一节点消费部分消息,然后交由后续节点继续处理,最终可以有处理结果也可以没有处理结果,读者可以不用理会什么纯的、不纯的责任链模式。同时,请读者注意handlerMessage方法前的final关键字,可以阅读模板方法模式。

我们定义三个具体的处理者,以便可以组成一个链,如代码清单15所示。

public class ConcreteHandler1 extends Handler {
     //定义自己的处理逻辑
     protected Response echo(Request request) {
             //完成处理逻辑
             return null;
     }
     //设置自己的处理级别
     protected Level getHandlerLevel() {
             //设置自己的处理级别
             return null;
     }
}
public class ConcreteHandler2 extends Handler {
     //定义自己的处理逻辑
     protected Response echo(Request request) {
             //完成处理逻辑
             return null;
     }
     //设置自己的处理级别
     protected Level getHandlerLevel() {
             //设置自己的处理级别
             return null;
     }
}
public class ConcreteHandler3 extends Handler {
     //定义自己的处理逻辑
     protected Response echo(Request request) {
             //完成处理逻辑
             return null;
     }
     //设置自己的处理级别
     protected Level getHandlerLevel() {
             //设置自己的处理级别
             return null;
     }
}

在处理者中涉及三个类:Level类负责定义请求和处理级别,Request类负责封装请求,Response负责封装链中返回的结果,该三个类都需要根据业务产生,读者可以在实际应用中完成相关的业务填充,其框架代码如代码清单16所示。

public class Level {
     //定义一个请求和处理等级
}
public class Request {
     //请求的等级
     public Level getRequestLevel(){
             return null;
     }
}
public class Response {
     //处理者返回的数据
}

在场景类或高层模块中对链进行组装,并传递请求,返回结果,如代码清单17所示。

public class Client {
     public static void main(String[] args) {
             //声明所有的处理节点
             Handler handler1 = new ConcreteHandler1();
             Handler handler2 = new ConcreteHandler2();
             Handler handler3 = new ConcreteHandler3();
             //设置链中的阶段顺序1-->2-->3
             handler1.setNext(handler2);
             handler2.setNext(handler3);
             //提交请求,返回结果
             Response response = handler1.handlerMessage(new Request());
     }
}

在实际应用中,一般会有一个封装类对责任模式进行封装,也就是替代Client类,直接返回链中的第一个处理者,具体链的设置不需要高层次模块关系,这样,更简化了高层次模块的调用,减少模块间的耦合,提高系统的灵活性。

责任链模式的应用

责任链模式的优点

责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的,处理者可以不用知道请求的全貌(例如在J2EE项目开发中,可以剥离出无状态Bean由责任链处理),两者解耦,提高系统的灵活性。

责任链模式的缺点

责任链有两个非常显著的缺点:一是性能问题,每个请求都是从链头遍历到链尾,特别是在链比较长的时候,性能是一个非常大的问题。二是调试不很方便,特别是链条比较长,环节比较多的时候,由于采用了类似递归的方式,调试的时候逻辑可能比较复杂。

责任链模式的注意事项

链中节点数量需要控制,避免出现超长链的情况,一般的做法是在Handler中设置一个最大节点数量,在setNext方法中判断是否已经是超过其阈值,超过则不允许该链建立,避免无意识地破坏系统性能。

最佳实践

在通用源码中Handler是抽象类,融合了模板方法模式,每个实现类只要实现两个方法:echo方法处理请求和getHandlerLevel获得处理级别,想想单一职责原则和迪米特法则吧,通过融合模板方法模式,各个实现类只要关注的自己业务逻辑就成了,至于说什么事要自己处理,那就让父类去决定好了,也就是说父类实现了请求传递的功能,子类实现请求的处理,符合单一职责原则,各个实现类只完成一个动作或逻辑,也就是只有一个原因引起类的改变,我建议大家在使用的时候用这种方法,好处是非常明显的了,子类的实现非常简单,责任链的建立也是非常灵活的。

责任链模式屏蔽了请求的处理过程,你发起一个请求到底是谁处理的,这个你不用关心,只要你把请求抛给责任链的第一个处理者,最终会返回一个处理结果(当然也可以不做任何处理),作为请求者可以不用知道到底是需要谁来处理的,这是责任链模式的核心,同时责任链模式也可以作为一种补救模式来使用。举个简单例子,如项目开发的时候,需求确认是这样的:一个请求(如银行客户存款的币种),一个处理者(只处理人民币),但是随着业务的发展(改革开放了嘛,还要处理美元、日元等),处理者的数量和类型都有所增加,那这时候就可以在第一个处理者后面建立一个链,也就是责任链来处理请求,如果是人民币,好,还是第一个业务逻辑来处理;如果是美元,好,传递到第二个业务逻辑来处理;日元、欧元……这些都不用在对原有的业务逻辑产生很大改变,通过扩展实现类就可以很好地解决这些需求变更的问题。

责任链在实际的项目中使用也是比较多的,我曾经做过这样一个项目,界面上有一个用户注册功能,注册用户分两种,一种是VIP用户,也就是在该单位办理过业务的,一种是普通用户,一个用户的注册要填写一堆信息,VIP用户只比普通用户多了一个输入项:VIP序列号。注册后还需要激活,VIP和普通用户的激活流程也是不同的,VIP是自动发送邮件到用户的邮箱中就算激活了,普通用户要发送短信才能激活,为什么呢?获得手机号码以后好发广告短信啊!项目组就采用了责任链模式,甭管从前台传递过来的是VIP用户信息还是普通用户信息,统一传递到一个处理入口,通过责任链来完成任务的处理,类图如图5所示。

其中RegisterAction是继承了Strust2中的ActionSupport,实现HTTP传递过来对象组装,组装出一个HashMap对象UserInfoMap,传递给Handler的两个实现类,具体是哪个实现类来处理的,就由HashMap上的用户标识来做决定了,这个和上面我们举的例子很类似,读者可以自行实现。

参考文档