大量逻辑判断优化的思路——责任链模式复习总结及其和状态模式对比

俗话说，自己写的代码，6个月后也是别人的代码……复习！复习！复习！涉及的总结知识点如下：

• 责任链模式概念和例子
• 使用的条件
• 和状态模式的比较分析
• 责任链的优缺点
• 纯的责任链和不纯的责任链
• javax.servlet.Filter#doFilter()方法源码分析
• 基于AOP思想，模拟一个拦截器

 

 　　前面说了一个状态模式，总结过程中发现和这个责任链的使用场景很类似，都是为了解耦大量复杂业务逻辑判断的，那么他们有什么不同呢？回忆状态模式——状态模式允许通过改变对象的内部状态而改变对象自身的行为，这个对象表现得就好像修改了它的类一样。

策略模式的孪生兄弟——对状态模式的深度复习总结

　　在之前也说了，状态模式关键是各个状态子类必须知道下一个状态是啥，且要把逻辑判断转移到各个状态子类中，客户端不需要了解状态迁移的顺序，且状态模式虽然类图还尼玛和策略模式几乎一样，但是策略目的是针对单一算法的运行时替换，客户端需要事先了解策略，主动去选择合适的策略，不存在状态的自动迁移！

　　在看责任链，Chain of Responsibility（CoR）——责任链模式，也叫职责链模式或者职责连锁模式，同状态模式一样，也是对象的行为模式之一，该模式构造一系列分别担当不同的职责的类的对象来共同完成一个任务，对象由每一个对象对其下家的引用而连接起来形成一条链，这些类的对象之间像链条一样紧密相连，而客户端发出的请求在这个链上传递，直到链上的某一个对象决定处理此请求，发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任，所以该模式被称作职责链模式。

　　它的特点是各个职责类（类比状态模式的状态类们）职责单一不彼此依赖，且职责自动转移，但是和状态模式不同的是，责任链模式的责任类不知道自己的下一个需要转移到的职责是哪个，等价于——发出完成某任务请求的客户端并不知道链上的哪一个对象最终处理这个请求，这个组装过程需要交给环境类去完成，所以非常灵活！

　　比如客户Client要完成一个任务，这个任务包括a,b,c,d四个部分，首先客户Client把任务交给A，A完成a部分之后，把任务交给B，B完成b部分……直到D完成d部分。再看，政府部分的某项工作，县政府先完成自己能处理的部分，不能处理的部分交给省政府，省政府再完成自己职责范围内的部分，不能处理的部分交给中央政府，中央政府最后完成该项工作。还有，软件窗口的消息传播……但是以上的责任的转移，或者说在责任链上的移动，各个责任类不知道具体顺序和下一个责任，链条的组装过程是环境类（或客户端完成的）。如图：

　　写一个例子，汽配厂组装汽车，有车身，车尾，车头……现在需要一条生产线组装汽车，代码实现：

 1 public abstract class CarController {
 2     /**
 3      * 控制组装车的组装过程
 4      */
 5     public abstract void ControlCar();
 6 }
 7 
 8 public class CarHead extends CarController {
 9     /**
10      * 具体的组装责任（任务）
11      */
12     @Override
13     public void ControlCar() {
14         System.out.println("组装汽车的头部");
15     }
16 }
17 
18 public class CarBody extends CarController {
19     @Override
20     public void ControlCar() {
21         System.out.println("组装汽车的身体");
22     }
23 }
24 
25 public class CarTail extends CarController {
26     @Override
27     public void ControlCar() {
28         System.out.println("组装汽车的尾部");
29     }
30 }
31 
32 public class MainClass {
33 
34     public static void main(String[] args) {
35         // 进行组装
36         CarController head = new CarHead();
37         CarController body = new CarBody();
38         CarController tail = new CarTail();
39 
40         // 手动的实现组装过程
41         head.ControlCar();
42         body.ControlCar();
43         tail.ControlCar();
44     }
45 }

View Code

　　貌似完成任务了，但是这样搞有问题，

　　第一：保不齐以后组装技术提高了，生产线上的组装顺序会变化，或者 多/少 几个组装部分。此时修改代码，不仅职责类需要修改，客户端也需要修改。违反了开闭原则。

　　第二：组装过程是很low的，完全没有实现自动组装！而是每次都要手动进行各个部件的组装。其实我只需要给生产线下一个指令，一个事先设计的组装流程就ok了，剩下的让生产线全自动的运行！

　　又多了个汽车美容，和宣传功能，现在优化代码：

public abstract class CarControllerB {
    /**
     * 以后各个责任类要持有的下一个对象引用
     */
    protected CarControllerB successor;

    public CarControllerB getSuccessor() {
        return successor;
    }

    public void setSuccessor(CarControllerB successor) {
        this.successor = successor;
    }

    /**
     * 控制组装车的组装过程
     */
    public abstract void ControlCar();
}

public class CarHeadB extends CarControllerB {
    /**
     * 具体的组装责任（任务）
     */
    @Override
    public void ControlCar() {
        System.out.println("组装汽车的头部");

        if (getSuccessor() != null) {
            getSuccessor().ControlCar();
        }
    }
}

public class CarBodyB extends CarControllerB {
    @Override
    public void ControlCar() {
        System.out.println("组装汽车的身体");

        if (getSuccessor() != null) {
            getSuccessor().ControlCar();
        }
    }
}

public class CarTailB extends CarControllerB {
    @Override
    public void ControlCar() {
        System.out.println("组装汽车的尾部");

        if (getSuccessor() != null) {
            getSuccessor().ControlCar();
        }
    }
}

public class CarDrumbeating extends CarControllerB {
    @Override
    public void ControlCar() {
        System.out.println("进行宣传工作");

        if (getSuccessor() != null) {
            getSuccessor().ControlCar();
        }
    }
}

public class CarCosmetology extends CarControllerB {
    @Override
    public void ControlCar() {
        System.out.println("给车美容");

        if (getSuccessor() != null) {
            getSuccessor().ControlCar();
        }
    }
}

View Code

　　记住，持有下一个责任类的对象因为必须不能是private的，否则无法被扩展！下面编写环境类

public class Client {

    /**
     * 在环境类（客户端）里按照业务需要，动态的组装各个职责类为一条链条
     */
    public void execute() {
        CarControllerB head = new CarHeadB();
        CarControllerB body = new CarBodyB();
        CarControllerB tail = new CarTailB();
        CarControllerB drumbeating = new CarDrumbeating();
        CarControllerB cosmetology = new CarCosmetology();

        // 灵活的组装生产线的顺序，目前规定，先组装头，之后尾部，最后身子！完成之后美容，宣传出去！
        head.setSuccessor(tail);
        tail.setSuccessor(body);
        body.setSuccessor(cosmetology);
        cosmetology.setSuccessor(drumbeating);

        // 自动的开启生产线，调用链条头部
        head.ControlCar();
    }
}

View Code

　　客户端调用

public class MainClassB {

    public static void main(String[] args) {
        Client client = new Client();
        client.execute();
    }
}

View Code

结果：

组装汽车的头部
组装汽车的尾部
组装汽车的身体
给车美容
进行宣传工作

---

 

　　后来，生成任务有变化，需要改变组装顺序，不宣传了，先放一放。那么直接在环境里修改链接的顺序，客户端不需要改变（甚至对客户端clinet，可以抽象出一个接口，每个组装链条都作为一个子类去实现该接口，我发现这里又有了策略模式的影子）

    /**
     * 在环境类（客户端）里按照业务需要，动态的组装各个职责类为一条链条
     */
    public void execute() {
        CarControllerB head = new CarHeadB();
        CarControllerB body = new CarBodyB();
        CarControllerB tail = new CarTailB();
        CarControllerB drumbeating = new CarDrumbeating();
        CarControllerB cosmetology = new CarCosmetology();

        // 灵活的组装生产线的顺序，目前规定，先组装头，之后尾部，最后身子！完成之后美容，宣传出去！
        head.setSuccessor(tail);
        tail.setSuccessor(body);
        body.setSuccessor(cosmetology);

        // 自动的开启生产线，调用链条头部
        head.ControlCar();
    }

View Code

组装汽车的头部
组装汽车的尾部
组装汽车的身体
给车美容

---

 

　　我曾经被人问过，每次都尼玛set一下写一行，set一下写一行，代码量不少啊，也麻烦！咋办，其实任何模式都不是一成不变的，还是那句话，设计模式最初于GoF提出，源码是c++，也就是说，不要纠结具体的代码实现，不要纠结具体的类图，模式是一种思想，面向对象编程思想的体现。我这样做，这是之前的抽象处理类（接口）；

public abstract class CarControllerB {
    /**
     * 以后各个责任类要持有的下一个对象引用
     */
    protected CarControllerB successor;

    public CarControllerB getSuccessor() {
        return successor;
    }

    public void setSuccessor(CarControllerB successor) {
        this.successor = successor;
    }

    /**
     * 控制组装车的组装过程
     */
    public abstract void ControlCar();
}

View Code

　　改进之后：

public abstract class CarControllerB {
    /**
     * 以后各个责任类要持有的下一个对象引用
     */
    protected CarControllerB successor;

    public CarControllerB getSuccessor() {
        return successor;
    }

    public CarControllerB setSuccessor(CarControllerB successor) {
        this.successor = successor;

        return this.successor;
    }

    /**
     * 控制组装车的组装过程
     */
    public abstract void ControlCar();
}

View Code

　　当然之前的代码还是可以用的，只不过client类变的更加简单了为：

public class Client {

    /**
     * 在环境类（客户端）里按照业务需要，动态的组装各个职责类为一条链条
     */
    public void execute() {
        CarControllerB head = new CarHeadB();
        CarControllerB body = new CarBodyB();
        CarControllerB tail = new CarTailB();
        CarControllerB drumbeating = new CarDrumbeating();
        CarControllerB cosmetology = new CarCosmetology();

        // 灵活的组装生产线的顺序，目前规定，先组装头，之后尾部，最后身子！完成之后美容，宣传出去！
        head.setSuccessor(tail).setSuccessor(body).setSuccessor(cosmetology).setSuccessor(drumbeating);

        // 自动的开启生产线，调用链条头部
        head.ControlCar();
    }
}

View Code

注意，该例子比较简单，具体任务都是用打印实现的，一会儿介绍一个servlet的过滤器。

 

　　要实现Chain of Responsibility模式，需要满足的基本条件是什么？

 

1. 不同的职责对象需要完成不同的职责，且职责单一！
2. 对象链的组织，需要将某任务的所有职责执行对象以链的形式加以组织。
3. 消息或请求的传递。将消息或请求沿着对象链传递，以让处于对象链中的对象得到处理机会。
4. 任务的完成。任务对象本身不知道，也不负责职责链条的终止或者开始是哪一个职责类，它们只需要持有下一个责任对象的引用，且判断下引用空不空，而具体顺序和开始，结束的设置都交给责任链的控制类（环境类）完成，如果有多个链条，那么可以抽象一个接口。 

　　

　　说说责任链模式的各个角色，画出责任链模式的类图

　　●抽象处理者(Handler)角色：定义出一个处理请求的抽象接口。如果需要接口可以定义出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。

　　●具体处理者(ConcreteHandler)角色：具体处理者作为子类去继承（实现）抽象处理角色，当他们接到请求后，可以选择将请求处理掉，或者忽略而将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。

 

　　说说责任链模式和状态模式的区别

　　不可否认，状态模式也好，责任链模式也罢，都能解耦和优化大量的逻辑判断……

　　责任链模式使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这个对象练成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。各个责任类不知道也没必要知道下一个责任对象是谁！由环境类统一设置顺序和谁连接到链条，谁不连接到链条……从代码中我们可以看出，职责链在client（环境类）连接，也就是说，如果我们的生产线一旦改变，比如说我们不需要美容了，我们需要增加新的组装项目了，或者是先组装车头后，直接请求去保存到仓库……这都是很容易实现的，职责链模式要比状态模式灵活很多。

　　但是，这时候有人要问，既然他们都可以解决逻辑判断的分支过多的问题，那么，是不是责任链模式比状态模式好呢？

　　职责链模式过于灵活，在客户端使用时，需要环境去确定下一个对象是谁，一些列的set操作……在多次设置的时候很容易出问题，而且状态模式是一个对象的内在状态发生改变（一个对象，相对比较稳定，处理完一个对象下一个对象的处理一般都已确定），而职责链模式是多个对象之间的改变（多个对象之间的话，就会出现某个对象不存在的情景，就像之前讲状态模式时的公司请假系统，可能存在不同级别，不同类型员工请假流程不一样，此时用状态模式不太好），这也说明他们两个模式处理的情况不同。

　　其实，这两个设计模式最大的区别就是

• 状态模式是让各个状态对象自己知道其下一个处理的对象是谁，即在编译时便设定。相当于If ，else-if，else-if……， 设计思路是把逻辑判断转移到各个State类的内部实现(相当于If，else If)，执行时客户端通过调用环境—Context类的方法来间接执行状态类的行为，客户端不直接和状态交互。
• 职责链模式中的各个对象并不指定其下一个处理的对象到底是谁，只有在客户端才设定某个类型的链条，请求发出后穿越链条，直到被某个职责类处理或者链条结束。本质相当于swich-case，设计思路是把各个业务逻辑判断封装到不同职责类，且携带下一个职责的对应引用，但不像状态模式那样需要明确知道这个引用指向谁，而是在环境类设置链接方式或者过程。使用时，向链的第一个子类的执行方法传递参数就可以。客户端去通过环境类调用责任链，全自动运转起来。

 　　针对具体业务，有人用状态模式，从头到尾提前定义好下一个处理的对象，有人采用责任链，随时都有可能调整链的顺序……甚至不复杂的业务判断，或者只需要使用一次的情景下，那就没必要搞这些鸡毛模式，本着够用原则和具体业务的适合原则！

 

　　责任链模式有什么优缺点？

　　优点：

• 责任的分担。每个类只需要处理自己该处理的工作（不该处理的传递给下一个对象完成），明确各类的责任范围，符合类的最小封装原则。
• 可以根据需要自由组合工作流程。如工作流程发生变化，可以通过重新分配对象链便可适应新的工作流程。
• 类与类之间可以以松耦合的形式加以组织。
• 各个任务（责任）类不需要了解自己下一个责任（任务）是谁，交给客户端完成

　　缺点：因为处理时以链的形式在对象间传递消息，根据实现方式不同，有可能会影响处理的速度，增加代码量，同之前的道理，为了提高灵活性，会牺牲代码量！

 

　　责任链模式的分类：纯的责任链和不纯的责任链

　　作为一个补充知识，非重点。

　　纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，二是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又把该责任向下传的情况。在一个纯的责任链里，一个请求必须被某一个处理者对象完全所接收。

　　不纯的责任链模式，一个请求可以最终不被任何接收端对象所接收。纯的责任链模式的实际例子很难找，一般看到的例子均是不纯的责任链模式实现。在实际的系统里，纯的责任链很难找到。如果认为责任链不纯便不是责任链模式，那么责任链模式便不会有太大意义了。

 

　　JDK中使用责任链的例子：javax.servlet.Filter#doFilter()——servlet的过滤器

　　在Web应用里，过滤器位于客户端和Web应用程序之间，用于检查和修改两者之间流过的请求和响应数据，在请求到达Servlet/JSP之前，过滤器截获请求（拦截器），之后在进行实际业务的处理，处理完毕最后的响应返回给客户端之前，过滤器再次截获响应进行一些操作（检验等）。多个过滤器形成一个过滤器链，过滤器链中不同过滤器的先后顺序由部署文件web.xml中过滤器映射的顺序决定。最先截获客户端请求的过滤器将最后截获Servlet/JSP的响应信息。当然了，servlet的过滤器还使用了比如装饰模式，以后总结。

　　servlet过滤器经典案例

• 全站中文乱码解决的过滤器
• 脏话，敏感词汇的过滤器
• HTML标记过滤器
• 全站GZIP压缩过滤器

　　下面简单看一个小例子，测试类需要实现javax.servlet.Filter#doFilter()接口，demo例子

 1 public class FilterDemo implements Filter {
 2     /**
 3      * 容器执行，完成过滤器初始化工作
 4      *
 5      * @param filterConfig FilterConfig
 6      * @throws ServletException
 7      */
 8     @Override
 9     public void init(FilterConfig filterConfig) throws ServletException {
10         System.out.println("过滤器初始化完毕");
11     }
12 
13     /**
14      * 容器调用，每次请求前，响应前，都要经过该方法去过滤
15      *
16      * @param servletRequest ServletRequest
17      * @param servletResponse ServletResponse
18      * @param filterChain FilterChain
19      * @throws IOException
20      * @throws ServletException
21      */
22     @Override
23     public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
24         System.out.println("过滤器执行了!");
25         // 让下一个资源执行
26         filterChain.doFilter(servletRequest, servletResponse);
27     }
28 
29     /**
30      * 容器执行，完成过滤器销毁工作
31      */
32     @Override
33     public void destroy() {
34         System.out.println("过滤器销毁完毕");
35     }
36 }

View Code

　　配置web.xml，指定哪些资源需要拦截 

         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    
        FilterDemo
        class>com.dashuai.servlet1.FilterDemoclass>
    

    
        FilterDemo
        /*
    

View Code

　　执行过滤器的结果：

信息: Server startup in 35 ms
[2016-02-06 03:24:30,849] Artifact demo1:war exploded: Artifact is being deployed, please wait...
Connected to server
二月 06, 2016 3:24:30 下午 org.apache.catalina.deploy.WebXml setVersion
警告: Unknown version string [3.1]. Default version will be used.
过滤器初始化完毕
[2016-02-06 03:24:31,125] Artifact demo1:war exploded: Artifact is deployed successfully
[2016-02-06 03:24:31,126] Artifact demo1:war exploded: Deploy took 276 milliseconds
过滤器执行了!
过滤器执行了!
过滤器执行了!
过滤器执行了!
二月 06, 2016 3:24:40 下午 org.apache.catalina.startup.HostConfig deployDirectory
信息: Deploying web application directory D:\apache-tomcat-7.0.67\webapps\manager
二月 06, 2016 3:24:40 下午 org.apache.catalina.startup.HostConfig deployDirectory
信息: Deployment of web application directory D:\apache-tomcat-7.0.67\webapps\manager has finished in 68 ms
D:\apache-tomcat-7.0.67\bin\catalina.bat stop
Using CATALINA_BASE:   "C:\Users\Administrator\.IntelliJIdea14\system\tomcat\Tomcat_7_0_67_jspservlet1"
Using CATALINA_HOME:   "D:\apache-tomcat-7.0.67"
Using CATALINA_TMPDIR: "D:\apache-tomcat-7.0.67\temp"
Using JRE_HOME:        "D:\Java\jdk1.8.0_60"
Using CLASSPATH:       "D:\apache-tomcat-7.0.67\bin\bootstrap.jar;D:\apache-tomcat-7.0.67\bin\tomcat-juli.jar"
二月 06, 2016 3:24:46 下午 org.apache.catalina.core.StandardServer await
信息: A valid shutdown command was received via the shutdown port. Stopping the Server instance.
二月 06, 2016 3:24:46 下午 org.apache.coyote.AbstractProtocol pause
信息: Pausing ProtocolHandler ["http-apr-8888"]
二月 06, 2016 3:24:46 下午 org.apache.coyote.AbstractProtocol pause
信息: Pausing ProtocolHandler ["ajp-apr-21963"]
二月 06, 2016 3:24:46 下午 org.apache.catalina.core.StandardService stopInternal
信息: Stopping service Catalina
过滤器销毁完毕
二月 06, 2016 3:24:46 下午 org.apache.coyote.AbstractProtocol stop
信息: Stopping ProtocolHandler ["http-apr-8888"]
二月 06, 2016 3:24:46 下午 org.apache.coyote.AbstractProtocol stop
信息: Stopping ProtocolHandler ["ajp-apr-21963"]
二月 06, 2016 3:24:46 下午 org.apache.coyote.AbstractProtocol destroy
信息: Destroying ProtocolHandler ["http-apr-8888"]
二月 06, 2016 3:24:46 下午 org.apache.coyote.AbstractProtocol destroy
信息: Destroying ProtocolHandler ["ajp-apr-21963"]
Disconnected from server

View Code

　　分析过滤器的执行过程，先看过滤器生命周期：

1. 应用被加载时就完成了过滤器的实例化和初始化，只有一次
2. 针对用户的每次资源访问，容器都会调用doFilter方法
3. 应用被卸载或服务器停止时，会执行destory方法

　　首先访问了 http://localhost:8888/index.jsp页面，之后请求资源被拦截，进入过滤器，当处理逻辑完毕，返回响应资源时，类似数据结构里的栈，最开始的过滤器最后一个被调用，反过来通过过滤器，才把资源返回给页面。

　　使用debug进行源码分析，我发现它是有这样一个类调用的doFilter方法，它实现了FilterChain, CometFilterChain两个接口，其中FilterChain接口是真正的抽象策略接口

　　ApplicationFilterChain类是个final类，在这里可以把它直接当作抽象的处理策略类（过滤器接口），它做了一些事情，针对责任链模式的使用，它用一个 ApplicationFilterConfig 类的数组 filters 保存各个具体的过滤器对象

　　ApplicationFilterConfig 是一个Filter 的容器，它的主要作用是读取web.xml文件配置

　　而且该类的内部聚合了一个Filter接口的引用，该Filter就是之前测试类FilterDemo实现的那个接口

　　仔细观察发现，Filter接口的方法doFilter的参数有一个FilterChain接口类型的参数，如此把两个doFilter结合

　　这样测试类实现Filter接口，同时该接口的doFilter方法里又有一个责任链模式里真正抽象的处理策略接口 FilterChain 的参数，在方法内部调用接口FilterChain的doFilter方法

　　在实现类FilterDemo里使用

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        System.out.println("过滤器执行了!");
        // 让下一个资源执行
        filterChain.doFilter(servletRequest, servletResponse);
    }

View Code

　　方法内的doFilter就是真正的抽象策略类接口的抽象方法，而ApplicationFilterChain类又实现了FilterChain接口，ApplicationFilterChain类内部聚合了所有的过滤器Filter，如此就清晰了。继续debug，发现程序进入了这个类：StandardWrapperValve

　　其中有这样两句代码：

　　　　我发现里面有我想要的，开始说的责任链模式里抽象处理策略类！ApplicationFilterChain类，而这个类的引用被一个ApplicationFilterFactory（应该是使用了工厂模式）的createFilterChain方法实例化，进入ApplicationFilterFactory查看createFilterChain方法：

发现别有洞天！原来该工厂类的createFilterChain方法里实例化了之前的抽象处理策略类，继续；

　　调用了addFilter方法，回到抽象处理策略类，发现这是在初始化Filter数组！！！

void addFilter(ApplicationFilterConfig filterConfig) {
        ApplicationFilterConfig[] newFilters = this.filters;
        int len$ = newFilters.length;

        for(int i$ = 0; i$ < len$; ++i$) {
            ApplicationFilterConfig filter = newFilters[i$];
            if(filter == filterConfig) {
                return;
            }
        }

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

        this.filters[this.n++] = filterConfig;
    }

View Code

发现了貌似是JDK一个傻逼问题！？开头明明定义了常量10啊，为啥里面还写10这个魔鬼数字呢？且这个常量10没有被使用！我去！！！匪夷所思。高人可以指点！

　　StandardWrapperValue类在初始化过滤器保存的数组之后，就调用ApplicationFilterChain的doFilter方法

　　而ApplicationFilterChain的doFilter方法内部，又调用了自己的私有工具方法internalDoFilter方法

    public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException {
        if(Globals.IS_SECURITY_ENABLED) {
            final ServletRequest req = request;
            final ServletResponse res = response;

            try {
                AccessController.doPrivileged(new PrivilegedExceptionAction() {
                    public Void run() throws ServletException, IOException {
                        ApplicationFilterChain.this.internalDoFilter(req, res);
                        return null;
                    }
                });
            } catch (PrivilegedActionException var7) {
                Exception e = var7.getException();
                if(e instanceof ServletException) {
                    throw (ServletException)e;
                }

                if(e instanceof IOException) {
                    throw (IOException)e;
                }

                if(e instanceof RuntimeException) {
                    throw (RuntimeException)e;
                }

                throw new ServletException(e.getMessage(), e);
            }
        } else {
            this.internalDoFilter(request, response);
        }

    }

View Code

　　显然internalDoFilter方法里的filter.doFilter(request, response, this);就是调用我们前面创建的测试类FilterDemo中的doFilter()方法。

　　而FilterDemo 中的doFilter()方法会继续调用 chain.doFilter(request, response); 方法，而这个 chain 其实就是 ApplicationFilterChain，所以调用过程又回到了上面调用 doFilter 和调用 internalDoFilter 方法，这样执行直到里面的过滤器全部执行。太多了，差不多可以了，大体就是：

1. 在StandardWrapperValue类的invoke()方法中调用ApplicationFilterFactory类的createFilterChain()方法去初始化ApplicationFilterChain对象，如何初始化？下面
2. 在ApplicationFilterFactory类的createFilterChain()方法中又调用ApplicationFilterChain类的addFilter()方法
3. 在ApplicationFilterChain类的addFilter()方法中给ApplicationFilterConfig数组初始化等等
4. 之后，StandardWrapperValue类的invoke方法继续执行，调用ApplicationFilterChain这个抽象策略类的doFilter方法
5. 在ApplicationFilterChain类中的doFilter方法使用了ApplicationFilterConfig这个读取过滤器配置的类的一些方法获得我自己定义的过滤器FilterDemo，去调用它的doFilter方法
6. 自定义的doFilter方法内部又调用FilterChain的Dofilter方法，恰恰就是ApplicationFilterChain实现的doFilter方法，如此往复。

简单的局部的类图如下：

 

　　这样一个情景，有一个restful接口，需要用户输入很多参数，自然在调用之前需要多参数进行过滤校验，之后在执行真正的业务逻辑处理，请结合AOP编写一个拦截器

　　什么是AOP，这里不表，且目前我给了两个实现模拟的例子，一个是用了代理模式+责任链，一个是利用list集合列表进行控制，看这篇总结的文章：

 

代理模式总结——用代理模式结合责任链编写拦截器