Java设计模式(十七)----责任链模式

责任链模式 一、 概念 二、 引子 三、 结构 四、 具体案例

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

二、引子 从击鼓传花谈起   击鼓传花是一种热闹而又紧张的饮酒游戏。在酒宴上宾客依次坐定位置,由一人击鼓,击鼓的地方与传花的地方是分开的,以示公正。开始击鼓时,花束就开始依次传递,鼓声一落,如果花束在某人手中,则该人就得饮酒。   比如说,贾母、贾赦、贾政、贾宝玉和贾环是五个参加击鼓传花游戏的传花者,他们组成一个环链。击鼓者将花传给贾母,开始传花游戏。花由贾母传给 贾赦,由贾赦传给贾政,由贾政传给贾宝玉,又贾宝玉传给贾环,由贾环传回给贾母,如此往复,如下图所示。当鼓声停止时,手中有花的人就得执行酒令。

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

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

  责任链模式涉及到的角色如下所示:   ●抽象处理者(Handler)角色:定义出一个处理请求的接口。如果需要,接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。上图中Handler类的聚合关系给出了具体子类对下家的 引用,抽象方法handleRequest()规范了子类处理请求的操作。   ●具体处理者(ConcreteHandler)角色:具体处理者接到请求后,可以选择将请求处理掉,或者将请求传给下家。由于具体处理者持有对下家的引用,因此,如果需要,具体处理者可以访问下家。

源代码 抽象处理者角色

package ChainOfResponsibility;
//抽象处理角色
public abstract class Handler {

    /**
     * 持有后继的责任对象
     */
    protected Handler successor;//英语单词翻译为继任者的意思

    /**
     * 示意处理请求的方法,虽然这个示意方法是没有传入参数的 但实际是可以传入参数的,根据具体需要来选择是否传递参数
     */
    public abstract void handleRequest();

    /**
     * 取值方法
     */
    public Handler getSuccessor() {
        return successor;
    }

    /**
     * 赋值方法,设置后继的责任对象
     */
    public void setSuccessor(Handler successor) {
        this.successor = successor;
    }

}

具体处理者角色

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

}

客户端

package ChainOfResponsibility;

public class Client {

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

}

结果: 放过请求 处理请求

可以看出,客户端创建了两个处理者对象,并指定第一个处理者对象的下家是第二个处理者对象,而第二个处理者对象没有下家。然后客户端将请求传递给第一个处理者对象。   由于本示例的传递逻辑非常简单:只要有下家,就传给下家处理;如果没有下家,就自行处理。因此,第一个处理者对象接到请求后,会将请求传递给第二个处理者对象。由于第二个处理者对象没有下家,于是自行处理请求。活动时序图如下所示。

四、具体案例 来考虑这样一个功能:申请聚餐费用的管理。   很多公司都是这样的福利,就是项目组或者是部门可以向公司申请一些聚餐费用,用于组织项目组成员或者是部门成员进行聚餐活动。   申请聚餐费用的大致流程一般是:由申请人先填写申请单,然后交给领导审批,如果申请批准下来,领导会通知申请人审批通过,然后申请人去财务领取费用,如果没有批准下来,领导会通知申请人审批未通过,此事也就此作罢。   不同级别的领导,对于审批的额度是不一样的,比如,项目经理只能审批500元以内的申请;部门经理能审批1000元以内的申请;而总经理可以审核任意额度的申请。   也就是说,当某人提出聚餐费用申请的请求后,该请求会经由项目经理、部门经理、总经理之中的某一位领导来进行相应的处理,但是提出申请的人并不知道最终会由谁来处理他的请求,一般申请人是把自己的申请提交给项目经理,或许最后是由总经理来处理他的请求。   可以使用责任链模式来实现上述功能:当某人提出聚餐费用申请的请求后,该请求会在 项目经理—〉部门经理—〉总经理 这样一条领导处理链上进行传递,发出请求的人并不知道谁会来处理他的请求,每个领导会根据自己的职责范围,来判断是处理请求还是把请求交给更高级别的领导,只要有领导处理了,传递就结束了。   需要把每位领导的处理独立出来,实现成单独的职责处理对象,然后为它们提供一个公共的、抽象的父职责对象,这样就可以在客户端来动态地组合职责链,实现不同的功能要求了。

源代码 抽象处理者角色类

package ChainOfResponsibility1;

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);
}

具体处理者角色类

package ChainOfResponsibility1;

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;
    }

}
package ChainOfResponsibility1;

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;
    }

}
package ChainOfResponsibility1;

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;
    }

}

客户端

package ChainOfResponsibility1;

public class Client {

    public static void main(String[] args) {
        // 先要组装责任链
        Handler h1 = new ProjectManager();
        Handler h2 = new DeptManager();
        Handler h3 = new GeneralManager();

        h1.setSuccessor(h2);
        h2.setSuccessor(h3);

        // 开始测试
        String test1 = h1.handleFeeRequest("张三", 300);
        System.out.println("test1 = " + test1);
        String test2 = h1.handleFeeRequest("李四", 300);
        System.out.println("test2 = " + test2);
        System.out.println("---------------------------------------");

        String test3 = h1.handleFeeRequest("张三", 700);
        System.out.println("test3 = " + test3);
        String test4 = h1.handleFeeRequest("李四", 700);
        System.out.println("test4 = " + test4);
        System.out.println("---------------------------------------");

        String test5 = h1.handleFeeRequest("张三", 1500);
        System.out.println("test5 = " + test5);
        String test6 = h1.handleFeeRequest("李四", 1500);
        System.out.println("test6 = " + test6);
    }

}

结果:

纯的与不纯的责任链模式   一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个:一是承担责任,而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又 把责任向下传的情况。   在一个纯的责任链模式里面,一个请求必须被某一个处理者对象所接收;在一个不纯的责任链模式里面,一个请求可以最终不被任何接收端对象所接收。   纯的责任链模式的实际例子很难找到,一般看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式,这也许是有道理的。但是在实际的系统里,纯的责任链很难找到。如果坚持责任链不纯便不是责任链模式,那么责任链模式便不会有太大意义了。

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

public class TestFilter implements Filter{

    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {

        chain.doFilter(request, response);
    }

    public void destroy() {
    }

    public void init(FilterConfig filterConfig) throws ServletException {
    }

}

以上内容来自平时所看书籍和网络资源整理测试所得,如有不完善之处,欢迎指正!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ImportSource

设计模式-搞个接口,留有余地,让你我不再尴尬

设计模式,Design Patterns,Pattern,翻译为“模式”总感觉不够接地气,用今天的话来说可以叫“套路”。设计模式就是写代码的过程中一些常规打法和...

37512
来自专栏我的小碗汤

使用pprof优化golang性能

Donald E.Knuth说过一句非常著名的话,过早的优化是万恶之源。原文如下:

1974
来自专栏逍遥剑客的游戏开发

Nebula3中的委托(Delegate)

1233
来自专栏极乐技术社区

微信小游戏初体验

前言 上周【跳一跳】小游戏刷遍了朋友圈,也代表了微信小程序拥有了搭载游戏的功能(早该往这方面发展了,这才是应该有的形态嘛)。作为一个前端er,我的大刀早已经饥渴...

1.4K7
来自专栏NetCore

Framework 4.0 新关键字dynamic 之我见(二)

Hi,大家好,随着大家对VS2010的深入了解,对dynamic已经是越来越了解了,何时该用,何时不用已经非常熟悉了,原本不打算再写下去的,但感觉还有点东西需要...

20910
来自专栏ThoughtWorks

在项目中透明地引入特性开关

之前曾经推荐过崔立强的《使用功能开关更好地实现持续部署》,介绍Feature Toggle的实践。北京办公室的孟宇现在对这个问题有了新的思考,当我们抛却Spri...

4176
来自专栏Java3y

纳税服务系统七(投诉管理模块)【显示投诉信息、处理回复、我要投诉、Quartz自动受理、统计图FusionCharts】

投诉受理管理模块 接下来,就是来开发我们的投诉受理管理模块了…..我们来看看原型图与需求吧: 查询用户提交的投诉信息,可以根据投诉部门(部门A/B)、投诉时间段...

6167
来自专栏Java学习网

最佳编码实践:搞砸代码的10种方法

 这是一篇提供有效、实用编程方法的程序箴言,作者Susan Harkins是世界最大的技术期刊出版社的主编,具有多年的实践经验;在这篇文章里她重申“最佳编码实践...

2774
来自专栏java一日一条

Jsoup代码解读之四-parser(上)

作为Java世界最好的HTML 解析库,Jsoup的parser实现非常具有代表性。这部分也是Jsoup最复杂的部分,需要一些数据结构、状态机乃至编译器的知识。...

1001
来自专栏编程

使用JavaScript开发一个自修改代码

话说在25年前,我刚刚开始从事软件开发。在工作中,我遇到一个叫Dave的朋友,他曾在一家大型保险公司工作过几年,他的工作重点是开发支持一个名为“个人人寿保险”的...

3027

扫码关注云+社区

领取腾讯云代金券