博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
职责链
阅读量:4162 次
发布时间:2019-05-26

本文共 7455 字,大约阅读时间需要 24 分钟。

网址链接:

在阎宏博士的《JAVA与模式》一书中开头是这样描述责任链(Chain of Responsibility)模式的:

  责任链模式是一种对象的行为模式。在责任链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。


一、从击鼓传花谈起

  击鼓传花是一种热闹而又紧张的饮酒游戏。在酒宴上宾客依次坐定位置,由一人击鼓,击鼓的地方与传花的地方是分开的,以示公正。开始击鼓时,花束就开始依次传递,鼓声一落,如果花束在某人手中,则该人就得饮酒。

  比如说,贾母、贾赦、贾政、贾宝玉和贾环是五个参加击鼓传花游戏的传花者,他们组成一个环链。击鼓者将花传给贾母,开始传花游戏。花由贾母传给贾赦,由贾赦传给贾政,由贾政传给贾宝玉,又贾宝玉传给贾环,由贾环传回给贾母,如此往复,如下图所示。当鼓声停止时,手中有花的人就得执行酒令。

 

  击鼓传花便是责任链模式的应用。责任链可能是一条直线、一个环链或者一个树结构的一部分。

二、责任链模式的结构

  下面使用了一个责任链模式的最简单的实现。

三、责任链模式涉及到的角色如下所示:

  ●  抽象处理者(Handler)角色:定义出一个处理请求的接口。如果需要,接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。上图中Handler类的聚合关系给出了具体子类对下家的引用,抽象方法handleRequest()规范了子类处理请求的操作。

  ●  具体处理者(ConcreteHandler)角色:具体处理者接到请求后,可以选择将请求处理掉,或者将请求传给下家。由于具体处理者持有对下家的引用,因此,如果需要,具体处理者可以访问下家。

源代码

抽象处理者角色

public abstract class Handler {       /**     * 持有后继的责任对象     */    protected Handler successor;    /**     * 示意处理请求的方法,虽然这个示意方法是没有传入参数的     * 但实际是可以传入参数的,根据具体需要来选择是否传递参数     */    public abstract void handleRequest();    /**     * 取值方法     */    public Handler getSuccessor() {        return successor;    }    /**     * 赋值方法,设置后继的责任对象     */    public void setSuccessor(Handler successor) {        this.successor = successor;    }   }

具体处理者角色

public class ConcreteHandler extends Handler {    /**     * 处理方法,调用此方法处理请求     */    @Override    public void handleRequest() {        /**         * 判断是否有后继的责任对象         * 如果有,就转发请求给后继的责任对象         * 如果没有,则处理请求         */        if(getSuccessor() != null)        {                       System.out.println("放过请求");            getSuccessor().handleRequest();                   }else        {                       System.out.println("处理请求");        }    }}

客户端类

public class Client {    public static void main(String[] args) {        //组装责任链        Handler handler1 = new ConcreteHandler();        Handler handler2 = new ConcreteHandler();        handler1.setSuccessor(handler2);        //提交请求        handler1.handleRequest();    }}

可以看出,客户端创建了两个处理者对象,并指定第一个处理者对象的下家是第二个处理者对象,而第二个处理者对象没有下家。然后客户端将请求传递给第一个处理者对象。

  由于本示例的传递逻辑非常简单:只要有下家,就传给下家处理;如果没有下家,就自行处理。因此,第一个处理者对象接到请求后,会将请求传递给第二个处理者对象。由于第二个处理者对象没有下家,于是自行处理请求。活动时序图如下所示。

四、使用场景

  来考虑这样一个功能:申请聚餐费用的管理。

  很多公司都是这样的福利,就是项目组或者是部门可以向公司申请一些聚餐费用,用于组织项目组成员或者是部门成员进行聚餐活动。

  申请聚餐费用的大致流程一般是:由申请人先填写申请单,然后交给领导审批,如果申请批准下来,领导会通知申请人审批通过,然后申请人去财务领取费用,如果没有批准下来,领导会通知申请人审批未通过,此事也就此作罢。

  不同级别的领导,对于审批的额度是不一样的,比如,项目经理只能审批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);    }}

运行结果如下所示:

五、纯的与不纯的责任链模式

  一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个:一是承担责任,而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又 把责任向下传的情况。

  在一个纯的责任链模式里面,一个请求必须被某一个处理者对象所接收;在一个不纯的责任链模式里面,一个请求可以最终不被任何接收端对象所接收。

  纯的责任链模式的实际例子很难找到,一般看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式,这也许是有道理的。但是在实际的系统里,纯的责任链很难找到。如果坚持责任链不纯便不是责任链模式,那么责任链模式便不会有太大意义了。

六、责任链模式在Tomcat中的应用

  众所周知Tomcat中的Filter就是使用了责任链模式,创建一个Filter除了要在web.xml文件中做相应配置外,还需要实现javax.servlet.Filter接口。

 

七、使用场景

有多个对象可以处理同一个请求,具体哪个对象处理该请求待运行时刻再确定,客户端只需将请求提交到链上,而无须关心请求的处理对象是谁以及它是如何处理的。

在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。

可动态指定一组对象处理请求,客户端可以动态创建职责链来处理请求,还可以改变链中处理者之间的先后次序。

八、总结一把

职责链模式优点:

职责链模式使得一个对象无须知道是其他哪一个对象处理其请求,对象仅需知道该请求会被处理即可,接收者和发送者都没有对方的明确信息,且链中的对象不需要知道链的结构,由客户端负责链的创建,降低了系统的耦合度。

请求处理对象仅需维持一个指向其后继者的引用,而不需要维持它对所有的候选处理者的引用,可简化对象的相互连接。

在给对象分派职责时,职责链可以给我们更多的灵活性,可以通过在运行时对该链进行动态的增加或修改来处理一个请求的职责。

在系统中增加一个新的具体请求处理者时无须修改原有系统的代码,只需要在客户端重新建链即可,从这一点来看是符合“开闭原则”的。

职责链模式缺点:

因为一个请求没有明确的接收者,所以不能保证它一定会被处理,该请求可能一直到链的末端都得不到处理;一个请求也可能因职责链没有被正确配置而得不到处理。

对于比较长的职责链,请求的处理可能涉及到多个处理对象,系统性能将受到一定影响,而且在进行代码调试时不太方便。

如果建链不当,可能会造成循环调用,将导致系统陷入死循环。

转载地址:http://ijxxi.baihongyu.com/

你可能感兴趣的文章
xv6进程切换-swtch函数
查看>>
C语言中的变长数组 data[0]
查看>>
leveldb源码剖析--编码
查看>>
leveldb源码剖析-sstable
查看>>
产生死锁的必要条件和解决方法
查看>>
leveldb源码剖析--MemTable
查看>>
将数组分成两部分,使得这两部分的和的差最小
查看>>
leveldb源码剖析--TableBuilder生成磁盘sstable
查看>>
leveldb源码剖析--key-value形式的Block块中的数据存储格式
查看>>
leveldb源码剖析---filter block
查看>>
leveldb源码剖析--数据写入(DBImpl::Write)
查看>>
leveldb源码剖析---DBImpl::MakeRoomForWrite函数的实现
查看>>
leveldb源码剖析----compaction
查看>>
leveldb源码剖析---版本管理
查看>>
leveldb源码剖析---日志系统
查看>>
leveldb源码剖析---缓存系统
查看>>
leveldb源码剖析---迭代器设计
查看>>
从云风的coroutine库学习协程
查看>>
nginx源码剖析--从main函数开始
查看>>
Nginx源码剖析--ngx_cycle_s结构体分析
查看>>