一、责任链模式
责任链模式是一种对象的行为模式。在责任链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。
图一
责任链模式涉及到的角色如下所示:
● 抽象处理者(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 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中的应用
过对Tomcat8.5.5版本的源码进行学习,发现Tomcat中有2个地方用到了责任链模式,一个是管道中的阀门,另一个是过滤器链中的过滤器。下面我们分别来看一下这两个责任链模式具体是如何使用的。
Filter接口如下所示:
public interface Filter { public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain);
}
Filter接口是所有具体过滤器必须实现的接口,该接口有一个核心的方法doFilter,方法对Request和Response进行处理,注意第三个参数类型为FilterChain,传入该参数的目的是为了责任能够传递到下一个过滤器。
具体Filter如下所示:
public class MyFilter implements Filter{ @Override public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) { chain.doFilter(request,response);
}
}
首先根据需求对request和response进行处理,最后需要调用过滤器链中的doFilter方法以便责任能够传递到下一个过滤器。chain.doFilter(request,response),注意这个doFilter是FilterChain中的doFilter与Filter中的doFilter没有任何关系,名字虽然相同,但是参数是不一样的。FilterChain中的doFilter只有Request和Response两个参数,其实更好的命名方式应该是chain.doNextFilter(resquest,response)
那么,FilterChain是什么样的呢?我们上面已经看到了FilterChain的用法,也知道了FilterChain在调用doFilter(request,response)的时候需要有能力将任务传递到下一个Filter,因此我们可以推断,FilterChain中需要保存所有的Filter。在Tomcat的实现中,正是在FilterChain中用一个数组保存了所有的Filter,这不禁让我想起了java.util.ArrayList的实现。
在Tomcat中FilterChain也是一个接口,如下所示:
public interface FilterChain { public void doFilter(ServletRequest request, ServletResponse response);
}
而ApplicationFilterChain实现了FilterChain,其核心代码如下所示:
-
public void doFilter(ServletRequest request, ServletResponse response)
-
throws IOException, ServletException {
-
-
if( Globals.IS_SECURITY_ENABLED ) {
-
final ServletRequest req = request;
-
final ServletResponse res = response;
-
try {
-
java.security.AccessController.doPrivileged(
-
new java.security.PrivilegedExceptionAction<Void>() {
-
@Override
-
public Void run()
-
throws ServletException, IOException {
-
internalDoFilter(req,res);
-
return null;
-
}
-
}
-
);
-
} catch( PrivilegedActionException pe) {
-
Exception e = pe.getException();
-
if (e instanceof ServletException)
-
throw (ServletException) e;
-
else if (e instanceof IOException)
-
throw (IOException) e;
-
else if (e instanceof RuntimeException)
-
throw (RuntimeException) e;
-
else
-
throw new ServletException(e.getMessage(), e);
-
}
-
} else {
-
internalDoFilter(request,response);
-
}
-
}
-
-
private void internalDoFilter(ServletRequest request,
-
ServletResponse response)
-
throws IOException, ServletException {
-
-
// Call the next filter if there is one
-
if (pos < n) {
-
//在链执行过程中,当pos
-
ApplicationFilterConfig filterConfig = filters[pos++];
-
Filter filter = null;
-
try {
-
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(request, response, this);
-
}
-
-
support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
-
filter, request, response);
-
} catch (IOException e) {
-
if (filter != null)
-
support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
-
filter, request, response, e);
-
throw e;
-
} catch (ServletException e) {
-
if (filter != null)
-
support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
-
filter, request, response, e);
-
throw e;
-
} catch (RuntimeException e) {
-
if (filter != null)
-
support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
-
filter, request, response, e);
-
throw e;
-
} catch (Throwable e) {
-
e = ExceptionUtils.unwrapInvocationTargetException(e);
-
ExceptionUtils.handleThrowable(e);
-
if (filter != null)
-
support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
-
filter, request, response, e);
-
throw new ServletException
-
(sm.getString("filterChain.filter"), e);
-
}
-
return;
-
}
-
-
// We fell off the end of the chain -- call the servlet instance
-
try {
-
if (ApplicationDispatcher.WRAP_SAME_OBJECT) {
-
lastServicedRequest.set(request);
-
lastServicedResponse.set(response);
-
}
-
-
support.fireInstanceEvent(InstanceEvent.BEFORE_SERVICE_EVENT,
-
servlet, request, response);
-
if (request.isAsyncSupported()
-
&& !support.getWrapper().isAsyncSupported()) {
-
request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
-
Boolean.FALSE);
-
}
-
// Use potentially wrapped request from this point
-
if ((request instanceof HttpServletRequest) &&
-
(response instanceof HttpServletResponse)) {
-
-
if( Globals.IS_SECURITY_ENABLED ) {
-
final ServletRequest req = request;
-
final ServletResponse res = response;
-
Principal principal =
-
((HttpServletRequest) req).getUserPrincipal();
-
Object[] args = new Object[]{req, res};
-
SecurityUtil.doAsPrivilege("service",
-
servlet,
-
classTypeUsedInService,
-
args,
-
principal);
-
} else {
-
servlet.service(request, response);
-
}
-
} else {
-
servlet.service(request, response);
-
}
-
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
-
servlet, request, response);
-
} catch (IOException e) {
-
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
-
servlet, request, response, e);
-
throw e;
-
} catch (ServletException e) {
-
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
-
servlet, request, response, e);
-
throw e;
-
} catch (RuntimeException e) {
-
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
-
servlet, request, response, e);
-
throw e;
-
} catch (Throwable e) {
-
ExceptionUtils.handleThrowable(e);
-
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
-
servlet, request, response, e);
-
throw new ServletException
-
(sm.getString("filterChain.servlet"), e);
-
} finally {
-
if (ApplicationDispatcher.WRAP_SAME_OBJECT) {
-
lastServicedRequest.set(null);
-
lastServicedResponse.set(null);
-
}
-
}
-
-
}
可以看出在FilterChain的实现中确实是用数组来保存所有的过滤器,但是并不是直接保存的Filter类型,而是保存的FilterConfig类型,可以把FilterConfig当做Filter的包装类,我们可以通过filterConfig.getFilter()拿到Filter实例。在internalDoFilter方法中我们看到了FilterChain是如何实现责任的传递的,通过pos和n这两个变量来判断有没有传递到过滤器链的最后面,如果没有到最后,则取出当前过滤器并调用filter.doFilter的方法,在前面MyFilter的实现当中,它的doFilter方法在最后又调用了chain.doFilter(),从而保证了过滤器链能够将责任传递到下一个过滤器中。pos和n这两个变量的作用又让我联想到了ArrayList中的迭代器的实现。
客户端代码如下:
-
public class Client{
-
public static void main(String[] args) {
-
Request request = new Request();
-
Response response = new Response();
-
Filter filter1 = new MyFilter1();
-
Filter filter2 = new MyFilter2();
-
Filter filter3 = new MyFilter3();
-
FilterChain chain = new ApplicationFilterChain();
-
ApplicationFilterConfig filterConfig1 = new ApplicationFilterConfig(filter1);
-
ApplicationFilterConfig filterConfig2 = new ApplicationFilterConfig(filter2);
-
ApplicationFilterConfig filterConfig3 = new ApplicationFilterConfig(filter3);
-
chain.addFilter(filterConfig1);
-
chain.addFilter(filterConfig2);
-
chain.addFilter(filterConfig3);
-
chain.doFilter(request, response);
-
}
-
}
以下是Filter接口doFilter定义如下
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
过滤器链里面的filter在调用dofilter完成后,会继续调用chain.doFilter(request,response)方法,而这个chain其实就是applicationfilterchain,所以调用过程又回到了上面调用dofilter和调用internalDoFilter方法,这样执行直到里面的过滤器全部执行
当filte都调用完成后,它就会初始化相应的servlet,(例如jsp资源,默认它会开启一个 JspServlet对象)
// We fell off the end of the chain -- call the servlet instance
try {
if (ApplicationDispatcher.WRAP_SAME_OBJECT) {
lastServicedRequest.set(request);
lastServicedResponse.set(response);
}
support.fireInstanceEvent(InstanceEvent.BEFORE_SERVICE_EVENT,
servlet, request, response);
举个例子
假如访问的是个jsp,首先开启一个 JspServlet对象,然后该JspServlet对象会调用它的service方法
以下是个JspServlet的定义以及service方法的描述
public class JspServlet extends HttpServlet implements PeriodicEventListener
public void service (HttpServletRequest request,
HttpServletResponse response)
//jspFile may be configured as an init-param for this servlet instance //该jspUri代表访问jsp的相对路径
String jspUri = jspFile;
拿到该路径后它就会去判断该jsp是否已经预编译过
boolean precompile = preCompile(request);
serviceJspFile(request, response, jspUri, null, precompile);
如果已经编译则直接调用该jsp对应的servlet的_jspService方法
否则先编译在调用
假如是个html页面的访问则直接调用DefaultServlet做相应的处理
简单的分析了下,作为一个学习笔记吧
http://blog.csdn.net/abinge317/article/details/52882913
http://www.cnblogs.com/java-my-life/archive/2012/05/28/2516865.html