Java设计模式の责任链模式



在阎宏博士的《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 MainTest {

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

}

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

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

使用场景

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

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

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

  不同级别的领导,对于审批的额度是不一样的,比如,项目经理只能审批500元以内的申请;部门经理能审批1000元以内的申请;而总经理可以审核任意额度的申请。

  也就是说,当某人提出聚餐费用申请的请求后,该请求会经由项目经理、部门经理、总经理之中的某一位领导来进行相应的处理,但是提出申请的人并不知道最终会由谁来处理他的请求,一般申请人是把自己的申请提交给项目经理,或许最后是由总经理来处理他的请求。

  

  可以使用责任链模式来实现上述功能:当某人提出聚餐费用申请的请求后,该请求会在 项目经理—〉部门经理—〉总经理 这样一条领导处理链上进行传递,发出请求的人并不知道谁会来处理他的请求,每个领导会根据自己的职责范围,来判断是处理请求还是把请求交给更高级别的领导,只要有领导处理了,传递就结束了。

  需要把每位领导的处理独立出来,实现成单独的职责处理对象,然后为它们提供一个公共的、抽象的父职责对象,这样就可以在客户端来动态地组合职责链,实现不同的功能要求了。

  

具体源码:

package com.blankjor.handler;

/**
 * @desc 抽象处理者角色类
 * @author Blankjor
 * @date 2017年6月1日 下午11:04:16
 */
public abstract class Handler {
    /**
     * 持有下一个处理请求的对象
     */
    protected Handler successor = null;

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

    /**
     * 设值下一个处理请求的对象
     */
    public void setSuccessor(Handler handler) {
        this.successor = handler;
    }

    /**
     * 处理聚餐费用的报销
     */
    public abstract String handleFeeRequest(String user, double fee);

}

package com.blankjor.handler;

/**
 * @desc 项目经理
 * @author Blankjor
 * @date 2017年6月1日 下午11:11:28
 */
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 {
            if (getSuccessor() != null) {
                return getSuccessor().handleFeeRequest(user, fee);
            }
        }
        return str;
    }

}

package com.blankjor.handler;

/**
 * @desc 部门经理
 * @author Blankjor
 * @date 2017年6月1日 下午11:11:28
 */
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 {
            if (getSuccessor() != null) {
                return getSuccessor().handleFeeRequest(user, fee);
            }
        }
        return str;
    }

}

package com.blankjor.handler;

/**
 * @desc 总经理
 * @author Blankjor
 * @date 2017年6月1日 下午11:11:28
 */
public class GeneralManager 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 {
            if (getSuccessor() != null) {
                return getSuccessor().handleFeeRequest(user, fee);
            }
        }
        return str;
    }

}

package com.blankjor.handler;

/**
 * @desc 测试责任链模式
 * @author Blankjor
 * @date 2017年6月1日 下午11:20:00
 */
public class MainTest {
    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 = h3.handleFeeRequest("张三", 1100);
        System.out.println(test1);
        String test2 = h2.handleFeeRequest("张三", 800);
        System.out.println(test2);
        String test3 = h2.handleFeeRequest("张三", 1200);
        System.out.println(test3);
        String test4 = h1.handleFeeRequest("张三", 1300);
        System.out.println(test4);
    }

}

运行结果:

纯的与不纯的责任链模式

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

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

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

责任链模式在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 {
    }

}

  使用DEBUG模式所看到的结果如下

  其实在真正执行到TestFilter类之前,会经过很多Tomcat内部的类。顺带提一下其实Tomcat的容器设置也是责任链模式,注意被红色方框所圈中的类,从Engine到Host再到Context一直到Wrapper都是通过一个链传递请求。被绿色方框所圈中的地方有一个名为ApplicationFilterChain的类,ApplicationFilterChain类所扮演的就是抽象处理者角色,而具体处理者角色由各个Filter扮演。

  第一个疑问是ApplicationFilterChain将所有的Filter存放在哪里?

  答案是保存在ApplicationFilterChain类中的一个ApplicationFilterConfig对象的数组中。

    /**
     * Filters.
     */
    private ApplicationFilterConfig[] filters =
        new ApplicationFilterConfig[0];

  那ApplicationFilterConfig对象又是什么呢?

    ApplicationFilterConfig是一个Filter容器。以下是ApplicationFilterConfig类的声明:

/**
 * Implementation of a <code>javax.servlet.FilterConfig</code> useful in
 * managing the filter instances instantiated when a web application
 * is first started.
 *
 * @author Craig R. McClanahan
 * @version $Id: ApplicationFilterConfig.java 1201569 2011-11-14 01:36:07Z kkolinko $
 */

  当一个web应用首次启动时ApplicationFilterConfig会自动实例化,它会从该web应用的web.xml文件中读取配置的Filter的信息,然后装进该容器。

  刚刚看到在ApplicationFilterChain类中所创建的ApplicationFilterConfig数组长度为零,那它是在什么时候被重新赋值的呢?

    private ApplicationFilterConfig[] filters =
        new ApplicationFilterConfig[0];

  是在调用ApplicationFilterChain类的addFilter()方法时。

    /**
     * The int which gives the current number of filters in the chain.
     */
    private int n = 0;
    public static final int INCREMENT = 10;

    void addFilter(ApplicationFilterConfig filterConfig) {

        // Prevent the same filter being added multiple times
        for(ApplicationFilterConfig filter:filters)
            if(filter==filterConfig)
                return;

        if (n == filters.length) {
            ApplicationFilterConfig[] newFilters =
                new ApplicationFilterConfig[n + INCREMENT];
            System.arraycopy(filters, 0, newFilters, 0, n);
            filters = newFilters;
        }
        filters[n++] = filterConfig;

    }

  变量n用来记录当前过滤器链里面拥有的过滤器数目,默认情况下n等于0,ApplicationFilterConfig对象数组的长度也等于0,所以当第一次调用addFilter()方法时,if (n == filters.length)的条件成立,ApplicationFilterConfig数组长度被改变。之后filters[n++] = filterConfig;将变量filterConfig放入ApplicationFilterConfig数组中并将当前过滤器链里面拥有的过滤器数目+1。

  那ApplicationFilterChain的addFilter()方法又是在什么地方被调用的呢?

  是在ApplicationFilterFactory类的createFilterChain()方法中。

  1     public ApplicationFilterChain createFilterChain
  2         (ServletRequest request, Wrapper wrapper, Servlet servlet) {
  3
  4         // get the dispatcher type
  5         DispatcherType dispatcher = null;
  6         if (request.getAttribute(DISPATCHER_TYPE_ATTR) != null) {
  7             dispatcher = (DispatcherType) request.getAttribute(DISPATCHER_TYPE_ATTR);
  8         }
  9         String requestPath = null;
 10         Object attribute = request.getAttribute(DISPATCHER_REQUEST_PATH_ATTR);
 11
 12         if (attribute != null){
 13             requestPath = attribute.toString();
 14         }
 15
 16         // If there is no servlet to execute, return null
 17         if (servlet == null)
 18             return (null);
 19
 20         boolean comet = false;
 21
 22         // Create and initialize a filter chain object
 23         ApplicationFilterChain filterChain = null;
 24         if (request instanceof Request) {
 25             Request req = (Request) request;
 26             comet = req.isComet();
 27             if (Globals.IS_SECURITY_ENABLED) {
 28                 // Security: Do not recycle
 29                 filterChain = new ApplicationFilterChain();
 30                 if (comet) {
 31                     req.setFilterChain(filterChain);
 32                 }
 33             } else {
 34                 filterChain = (ApplicationFilterChain) req.getFilterChain();
 35                 if (filterChain == null) {
 36                     filterChain = new ApplicationFilterChain();
 37                     req.setFilterChain(filterChain);
 38                 }
 39             }
 40         } else {
 41             // Request dispatcher in use
 42             filterChain = new ApplicationFilterChain();
 43         }
 44
 45         filterChain.setServlet(servlet);
 46
 47         filterChain.setSupport
 48             (((StandardWrapper)wrapper).getInstanceSupport());
 49
 50         // Acquire the filter mappings for this Context
 51         StandardContext context = (StandardContext) wrapper.getParent();
 52         FilterMap filterMaps[] = context.findFilterMaps();
 53
 54         // If there are no filter mappings, we are done
 55         if ((filterMaps == null) || (filterMaps.length == 0))
 56             return (filterChain);
 57
 58         // Acquire the information we will need to match filter mappings
 59         String servletName = wrapper.getName();
 60
 61         // Add the relevant path-mapped filters to this filter chain
 62         for (int i = 0; i < filterMaps.length; i++) {
 63             if (!matchDispatcher(filterMaps[i] ,dispatcher)) {
 64                 continue;
 65             }
 66             if (!matchFiltersURL(filterMaps[i], requestPath))
 67                 continue;
 68             ApplicationFilterConfig filterConfig = (ApplicationFilterConfig)
 69                 context.findFilterConfig(filterMaps[i].getFilterName());
 70             if (filterConfig == null) {
 71                 // FIXME - log configuration problem
 72                 continue;
 73             }
 74             boolean isCometFilter = false;
 75             if (comet) {
 76                 try {
 77                     isCometFilter = filterConfig.getFilter() instanceof CometFilter;
 78                 } catch (Exception e) {
 79                     // Note: The try catch is there because getFilter has a lot of
 80                     // declared exceptions. However, the filter is allocated much
 81                     // earlier
 82                     Throwable t = ExceptionUtils.unwrapInvocationTargetException(e);
 83                     ExceptionUtils.handleThrowable(t);
 84                 }
 85                 if (isCometFilter) {
 86                     filterChain.addFilter(filterConfig);
 87                 }
 88             } else {
 89                 filterChain.addFilter(filterConfig);
 90             }
 91         }
 92
 93         // Add filters that match on servlet name second
 94         for (int i = 0; i < filterMaps.length; i++) {
 95             if (!matchDispatcher(filterMaps[i] ,dispatcher)) {
 96                 continue;
 97             }
 98             if (!matchFiltersServlet(filterMaps[i], servletName))
 99                 continue;
100             ApplicationFilterConfig filterConfig = (ApplicationFilterConfig)
101                 context.findFilterConfig(filterMaps[i].getFilterName());
102             if (filterConfig == null) {
103                 // FIXME - log configuration problem
104                 continue;
105             }
106             boolean isCometFilter = false;
107             if (comet) {
108                 try {
109                     isCometFilter = filterConfig.getFilter() instanceof CometFilter;
110                 } catch (Exception e) {
111                     // Note: The try catch is there because getFilter has a lot of
112                     // declared exceptions. However, the filter is allocated much
113                     // earlier
114                 }
115                 if (isCometFilter) {
116                     filterChain.addFilter(filterConfig);
117                 }
118             } else {
119                 filterChain.addFilter(filterConfig);
120             }
121         }
122
123         // Return the completed filter chain
124         return (filterChain);
125
126     }

  可以将如上代码分为两段,51行之前为第一段,51行之后为第二段。

  第一段的主要目的是创建ApplicationFilterChain对象以及一些参数设置。

  第二段的主要目的是从上下文中获取所有Filter信息,之后使用for循环遍历并调用filterChain.addFilter(filterConfig);将filterConfig放入ApplicationFilterChain对象的ApplicationFilterConfig数组中。

  那ApplicationFilterFactory类的createFilterChain()方法又是在什么地方被调用的呢?

  是在StandardWrapperValue类的invoke()方法中被调用的。

  

  由于invoke()方法较长,所以将很多地方省略。

    public final void invoke(Request request, Response response)
        throws IOException, ServletException {
   ...省略中间代码     // Create the filter chain for this request
        ApplicationFilterFactory factory =
            ApplicationFilterFactory.getInstance();
        ApplicationFilterChain filterChain =
            factory.createFilterChain(request, wrapper, servlet);
  ...省略中间代码
         filterChain.doFilter(request.getRequest(), response.getResponse());
  ...省略中间代码
    }

  那正常的流程应该是这样的:

  在StandardWrapperValue类的invoke()方法中调用ApplicationFilterChai类的createFilterChain()方法———>在ApplicationFilterChai类的createFilterChain()方法中调用ApplicationFilterChain类的addFilter()方法———>在ApplicationFilterChain类的addFilter()方法中给ApplicationFilterConfig数组赋值。

  根据上面的代码可以看出StandardWrapperValue类的invoke()方法在执行完createFilterChain()方法后,会继续执行ApplicationFilterChain类的doFilter()方法,然后在doFilter()方法中会调用internalDoFilter()方法。

  以下是internalDoFilter()方法的部分代码

        // Call the next filter if there is one
        if (pos < n) {       //拿到下一个Filter,将指针向下移动一位            //pos它来标识当前ApplicationFilterChain(当前过滤器链)执行到哪个过滤器
            ApplicationFilterConfig filterConfig = filters[pos++];
            Filter filter = null;
            try {          //获取当前指向的Filter的实例
                filter = filterConfig.getFilter();
                support.fireInstanceEvent(InstanceEvent.BEFORE_FILTER_EVENT,
                                          filter, request, response);

                if (request.isAsyncSupported() && "false".equalsIgnoreCase(
                        filterConfig.getFilterDef().getAsyncSupported())) {
                    request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
                            Boolean.FALSE);
                }
                if( Globals.IS_SECURITY_ENABLED ) {
                    final ServletRequest req = request;
                    final ServletResponse res = response;
                    Principal principal =
                        ((HttpServletRequest) req).getUserPrincipal();

                    Object[] args = new Object[]{req, res, this};
                    SecurityUtil.doAsPrivilege
                        ("doFilter", filter, classType, args, principal);

                } else {            //调用Filter的doFilter()方法
                    filter.doFilter(request, response, this);
                }

  这里的filter.doFilter(request, response, this);就是调用我们前面创建的TestFilter中的doFilter()方法。而TestFilter中的doFilter()方法会继续调用chain.doFilter(request, response);方法,而这个chain其实就是ApplicationFilterChain,所以调用过程又回到了上面调用dofilter和调用internalDoFilter方法,这样执行直到里面的过滤器全部执行。

  如果定义两个过滤器,则Debug结果如下:

参考:http://www.cnblogs.com/java-my-life/archive/2012/05/28/2516865.html

时间: 2024-10-12 16:24:47

Java设计模式の责任链模式的相关文章

java 设计模式 -- 责任链模式

设计模式 – 责任链模式 介绍: 责任链模式是一种动态行为模式,有多个对象,每一个对象分别拥有其下家的引用.连起来形成一条链.待处理对象则传到此链上,在此链进行传递,且待处理对象并不知道此会被链上的哪个对象处理,这使得我们能够动态的添加链上的对象而且分配责任. 纯责任链和非纯责任链 责任链分为两种.纯责任链和非纯责任链. 纯责任链是待处理对象request在处理对象handler链上传递,每一个处理对象handler处理request的一部分,到终于处理完毕.非纯责任链则是待处理对象reques

我的Java设计模式-责任链模式

今天来说说程序员小猿和产品就关于需求发生的故事.前不久,小猿收到了产品的需求. 产品经理:小猿,为了迎合大众屌丝用户的口味,我们要放一张图,要露点的. 小猿:......露点?你大爷的,让身为正义与纯洁化身的我做这种需求,还露点. 产品经理:误会误会,是放一张暴露一点点的,尺寸不大. 小猿:尼玛~能说清楚些吗,需求模棱两可的.不干,我要上报boss. 产品经理也一阵无语,这豆丁的事还上报boss.话说这上报也得走程序是吧,技术经理就不干了,"凭什么要跳过我,得经过我才能到boss".咦

java设计模式--责任链模式

责任链模式:将能够处理同一类请求的对象连成一条链,如果不能处理则传递给链上的下一个对象. //请假对象 public class QingjiaRequest { private String name; private int days; private String reason; public QingjiaRequest(String name, int days, String reason) { this.name = name; this.days = days; this.rea

[设计模式] 责任链模式之变种 - 责任链子

今天看到 wikipedia 的责任链模式,好奇之下搜寻相关文章,此文章主要参考 91大的 [.NET]重构之路系列v11 –用责任链模式打破讨厌的switch case 的变种作法,所以跟原本的责任链模式的设计思路不太相同,但结果相同, 所以阅读前,建议先看完91大的文章后,在来看这篇会比较能感觉出差异. ?这边先引用91大文章结尾结论中的补充来复习一下责任链的重点, 20120415 补充:责任链的用意在于把每个角色的职责分清楚,每个对象只需要做好自己的事,透过责任链的方式来组合,并完成使用

Java与设计模式-责任链模式

责任链模式属于行为型设计模式之一,怎么理解责任链?责任链是可以理解成数个对象首尾连接而成,每一个节点就是一个对象,每个对象对应不同的处理逻辑,直至有一个对象响应处理请求结束.这一种模式成为责任链模式. 生活中可以找到责任链模式的原型吗?这种例子很多,比如你要去买房子,首先是销售人员(对象1)接待你,你说想要百分之3的折扣,没问题,这时销售人员就有打百分之三折扣的权限,销售人员(对象1)进行处理.这时来了一个土豪,说要买10套,要百分之五的折扣,销售人员(对象1)没有百分之五折扣的权限,必须要想上

24天学会设计模式------责任链模式

林炳文Evankaka原创作品.转载请注明出处http://blog.csdn.net/evankaka/article/details/43210027 一.责任链模式(Chain of Responsibility Pattern) 1.简介 从名字上大概也能猜出这个模式的大概模样--系统中将会存在多个有类似处理能力的对象.当一个请求触发后,请求将在这些对象组成的链条中传递,直到找到最合适的"责任"对象,并进行处理.<设计模式>中给它的定义如下:使多个对象都有机会处理请

设计模式-责任链模式在实际项目中的使用

最近一次迭代,参与了公司数据应用平台的开发,其中负责的一块功能早早的就完成了代码的编写工作,即将进入测试阶段,因为有时间思考和总结代码编写中遇到的难题,便想着将代码做一次重构:其中优化的一个功能就是关于数据平台敏感字段的收集 功能描述:数据平台敏感字段的收集: 提供 service 方法,查询是否需要扫描表做触发式收集,指定具体实例与库的表,随机取 N 行(1~max(id) 之间):a.对每一行的每一个字段的值(取非 null 非空的值)做正则匹配 b. 对每一行的每一个字段的值看是否包含了敏

24种设计模式--责任链模式【Chain ofResponsibility Pattern】

中国古代对妇女制定了“三从四德”的道德规范,“三从”是指“未嫁从父.既嫁从夫.夫死从子”,也就是说一个女性,在没有结婚的时候要听从于父亲,结了婚后听从于丈夫,丈夫死了还要听儿子的,举个例子来说,一个女的要出去逛街,同样这样的一个请求,在她没有出嫁前她必须征得父亲的同意,出嫁之后必须获得丈夫的许可,那丈夫死了怎么办?一般都是男的比女的死的早,还要问问儿子是否允许自己出去逛街,估计你下边马上要问要是没有儿子怎么办?请示小叔子.侄子等等,在父系社会中,妇女只占从属地位,现在想想中国的妇女还是比较悲惨的

设计模式——责任链模式

责任链模式:将能够处理同一类请求的对象连成一条链所提交的请求沿着链传递,链上的对象逐个判断是否有能力处理该请求, 如果能则处理,如果不能则传递给链上的下一个对象.优点:将请求者和发送者解耦         简化对象的处理过程         可以通过改变链中的成员或成员的顺序来动态的新增或则删除责任. 缺点:不能保证请求一定会执行,可能或落到责任链之外. 不容易观察运行时的特征,处理请求的方法比较分散.实现方式:链表和非链表两种实现,但是使用集合和数组等非链表实现在实际开发中更方便更常用. 应用