JAVA设计模式—责任链模式(Chain Of Responsibility)

定义：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

类型：对象行为型模式

类图：

        首先来看一段代码：

[java]  view plain copy

1. public void test(int i, Request request){  
2.     if(i==1){  
3.         Handler1.response(request);  
4.     }else if(i == 2){  
5.         Handler2.response(request);  
6.     }else if(i == 3){  
7.         Handler3.response(request);  
8.     }else if(i == 4){  
9.         Handler4.response(request);  
10.     }else{  
11.         Handler5.response(request);  
12.     }  
13. }  

       代码的业务逻辑是这样的，方法有两个参数：整数i和一个请求request，根据i的值来决定由谁来处理request，如果i==1，由Handler1来处理，如果i==2，由Handler2来处理，以此类推。在编程中，这种处理业务的方法非常常见，所有处理请求的类有if…else…条件判断语句连成一条责任链来对请求进行处理，相信大家都经常用到。这种方法的优点是非常直观，简单明了，并且比较容易维护，但是这种方法也存在着几个比较令人头疼的问题：

• 代码臃肿：实际应用中的判定条件通常不是这么简单地判断是否为1或者是否为2，也许需要复杂的计算，也许需要查询数据库等等，这就会有很多额外的代码，如果判断条件再比较多，那么这个if…else…语句基本上就没法看了。
• 耦合度高：如果我们想继续添加处理请求的类，那么就要继续添加else if判定条件；另外，这个条件判定的顺序也是写死的，如果想改变顺序，那么也只能修改这个条件语句。

        既然缺点我们已经清楚了，就要想办法来解决。这个场景的业务逻辑很简单：如果满足条件1，则由Handler1来处理，不满足则向下传递；如果满足条件2，则由Handler2来处理，不满足则继续向下传递，以此类推，直到条件结束。其实改进的方法也很简单，就是把判定条件的部分放到处理类中，这就是责任连模式的原理。

 

责任连模式的结构

        责任连模式的类图非常简单，它由一个抽象地处理类和它的一组实现类组成：

• 抽象处理类：抽象处理类中主要包含一个指向下一处理类的成员变量nextHandler和一个处理请求的方法handRequest，handRequest方法的主要主要思想是，如果满足处理的条件，则有本处理类来进行处理，否则由nextHandler来处理。
• 具体处理类：具体处理类主要是对具体的处理逻辑和处理的适用条件进行实现。

        了解了责任连模式的大体思想之后，再看代码就比较好理解了：

//封装 请求
class Request{
	
}

//封装响应
class Response{
	
}

//抽象出来类
abstract class Handler {

	/**
	 * 持有后继的责任对象
	 */
	protected Handler next;

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

	/**
	 * 取值方法
	 */
	public Handler getNextHandler() {
		return next;
	}

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

//具体出来类
class ConcreteHandlerA extends Handler {

	@Override
	public Response handleRequest(Request req) {
		/**
		 * 判断是否有后继的责任对象,如果有，就转发请求给后继的责任对象 如果没有，则处理请求
		 */
		if (getNextHandler() != null) {
			System.out.println("有后继的责任链对象，不处理本次请求...A");
			getNextHandler().handleRequest(req);
		} else {
			System.out.println("没有后继的责任链对象，处理本次请求...A");
		}
		return null;
	}
}

class ConcreteHandlerB extends Handler {

	@Override
	public Response handleRequest(Request req) {
		if (getNextHandler() != null) {
			System.out.println("有后继的责任链对象，不处理本次请求...B");
			getNextHandler().handleRequest(req);
		} else {
			System.out.println("没有后继的责任链对象，处理本次请求...B");
		}
		return null;
	}
}

class ConcreteHandlerC extends Handler {

	@Override
	public Response handleRequest(Request req) {
		if (getNextHandler() != null) {
			System.out.println("有后继的责任链对象，不处理本次请求...C");
			getNextHandler().handleRequest(req);
		} else {
			System.out.println("没有后继的责任链对象，处理本次请求...C");
		}
		return null;
	}
}

//客户端调用
public class ChainOfResponsibilityClient {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		
		//组装责任链
        Handler handlerA = new ConcreteHandlerA();
        Handler handlerB = new ConcreteHandlerB();
        Handler handlerC = new ConcreteHandlerC();
        
        handlerA.setNextHandler(handlerB);
        handlerB.setNextHandler(handlerC);
        
        //提交请求
        Request req = new Request();
        handlerA.handleRequest(req);
		
	}
}

运行结果：

有后继的责任链对象，不处理本次请求...A
有后继的责任链对象，不处理本次请求...B
没有后继的责任链对象，处理本次请求...C

       代码中Level类是模拟判定条件；Request，Response分别对应请求和响应；抽象类Handler中主要进行条件的判断，这里模拟一个处理等级，只有处理类的处理等级高于Request的等级才能处理，否则交给下一个处理者处理。在Client类中设置好链的前后执行关系，执行时将请求交给第一个处理类，这就是责任连模式，它完成的功能与前文中的if…else…语句是一样的。

如果你看过Tomcat的源代码，一定对里边的管道模式(Pipeline)记忆犹新；如果您了解Servlet规范的话，一定会知道Filter；如果您使用过Struts2的话，一定清楚无处不在的interceptor。上边的这些概念可以说都是责任链模式的抽象，或者说变种。

 

责任链模式的优缺点

• 降低耦合度

该模式使得一个对象无需知道是其他哪一个对象处理其请求。对象仅需知道该请求会被“正确”地处理。接受者和发送者都没有对方明确的信息，且链中的对象无需知道链的结构。结果是，责任链可以简化对象的相互连接。它们仅需保持一个指向其后继者的引用，而不需要保持它所有的候选接受者的引用。

• 增强了给对象指派职责（Responsibility）的灵活性

当在对象中分派职责时，责任链给你更多的灵活性。你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。你可以将这种机制与静态的特例化处理对象的继承机制结合起来使用。

• 不保证被接受

既然一个请求没有明确的接受者，那么就不能保证它一定会被处理——该处理请求可能一直到链的末端都得不到处理。

责任链模式的适用场景

• 有多个对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
• 你想在不明确接收者的情况下，向多个对象中的一个提交一个请求。
• 可处理一个请求的对象集合应被动态指定。

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

总结

       责任链模式其实就是一个灵活版的if…else…语句，它就是将这些判定条件的语句放到了各个处理类中，这样做的优点是比较灵活了，但同样也带来了风险，比如设置处理类前后关系时，一定要特别仔细，搞对处理类前后逻辑的条件判断关系，并且注意不要在链中出现循环引用的问题。

参考：http://blog.csdn.net/zhengzhb/article/details/7568676