\(^_^)/ 设计模式_责任链模式

责任链模式就是这种“推卸”责任的模式，你的问题在我这里能解决我就解决，不行就把你推给另一个对象。

 

CoR(Chain of Responsibility) 即职责链设计模式：使多个对象都有机会处理请求（Request），从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止。

 

责任链是由一组处理请求的对象组成，责任链中的每一个对象都知道下一个对象的位置。一个链可以是一条线，一个树，也可以是一个环。 

    责任链的工作流程：发出请求的用户，不必知道是谁要处理整个请求，只需将请求发送给责任链，接到请求的对象，能处理就处理，不能处理转交给下个对象，直到处理完毕。   

    责任链的优点： 其实也就是请求发送者与处理者解耦，发送者不必知道谁来处理这个请求。 

    责任链的缺点： 每次发送请求，都需要经过一系列的对象来转交处理，转交处理的话是要消耗时间的。

 

 

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

责任链模式的提出是为了“解耦”，以应变系统需求的变更和不明确性。 

 

职责链设计模式 大概有三个角色：

（1）请求（Request）：封装请求信息

（2）处理器（Handler）：处理请求（Request），一个具体处理器一般只处理一种请 求，如果它不能处理传递过来的请求，那么它就把该请求传递给职责链中的下一个处理器（后继处理器 successor）。

（3）客户端（Client）：发送请求 

 

适用范围

1) 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。 

2) 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 

3) 可处理一个请求的对象集合应被动态指定。 

 

 

 

责任链模式由两个角色组成： 

1) 抽象处理者角色（Handler）：它定义了一个处理请求的接口。当然对于链子的不同实现，也可以在这个角色中实现后继链。 

2) 具体处理者角色（Concrete Handler）：实现抽象角色中定义的接口，并处理它所负责的请求。如果不能处理则访问它的后继者。 

 

 

从名字上大概也能猜出这个模式的大概模样——系统中将会存在多个有类似处理能力的对象。当一个请求触发后，请求将在这些对象组成的链条中传递，直到找到最合适的“责任”对象，并进行处理。 

 

 

责任链模式的纯与不纯的区别，就像黑猫、白猫的区别一样。不要刻意的去使自己的代码来符合一个模式的公式。只要能够使代码降低耦合、提高重用，满足系统需求并能很好的适应变化就好了。正所谓：管它黑猫白猫，抓住老鼠就是好猫！ 

纯的责任链模式：

规定一个具体处理者角色只能对请求作出两种动作：自己处理；传给下家。不能出现处理了一部分，把剩下的传给了下家的情况。而且请求在责任链中必须被处理，而不能出现无果而终的结局。 

不纯的责任链模式：

反之，则就是不纯的责任链模式。

一个是承担责任，二是把责任推给下一家。不允许出现某一个具体处理对象在承担了一部分责任后又把责任向下传的情况

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

 

 

责任链抽象类（AbstractHandler）：定义操作的接口，对外提供。设定和返回责任链的下一个对象。如果需要，接口可以定义出一个方法，以设定和返回下家的引用。这个角色通常由一个Java抽象类或Java接口实现。图中的聚合关系给出了具体子类对下家的引用，抽象方法handlerRequest（）规范了子类处理请求的操作。

责任链具体类（ConcreteHandler）：实现接口，继承抽象类。实现的方法逻辑【1、如果有下一个对象，则传递、调用下一个对象，2、如果没有下一个对象，处理请求。】 具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于处理者持有下家引用，因此，如果需要，具体处理者可以访问下家。

 

 

 

 

责任链模式的应用：

1、链结构的由来

   责任链模式并不创建出责任链。责任链的创建必须由系统的其它部分创建出来

   责任链模式减低了请求的发送端和接收端之间的耦合，使多个对象有机会处理这个请求。一个链可以是一条线，一个树，也可以是一个环。链的拓扑结构可以是单连通的或多连通的，责任链模式并不指定责任链的拓扑结构。但是责任链模式要求在同一时间里，命令只可以被传给一个下家（或被处理掉），而不可以传给多于一个下家。

   责任链的成员往往是一个更大结构的一部分。如果责任链的成员不存在，那么为了使用责任链模式，就必须创建它们。责任链的具体处理者对象可以是同一个具体处理者的实例

   在Internet Explorer的DHTML的DOM事件处理模型里，责任链则是DOM等级结构本身。

2、命令的传递

   在一个责任链上传递的可能不只有一个命令，而是多个命令。这些命令可以采取抽象化层、具体化层的多态性实现方式，从而可以将命令对象于责任链上的对象之间的责任分隔开，并将命令对象与传播命令的对象分隔开。

   如果责任链上的传播命令只有一个、且是固定的命令，那么这个命令不一定要对象化。

四、DHTML中的事件处理

1、Netscape的事件模型

   Netscape的事件处理机制叫做“事件捕捉”（Event Capturing）。在事件捕捉机制里，一个事件是从DOM的最高层向下传播，window对象是第一个接到事件上的，然后是document对象，如此向下。因此事件的产生对象反而是最后一个接到事件上的。

2、Internet Explorer的事件模型

   当一个事件发生在Internet Explorer所浏览的网页中时，Internet Explorer会使用DHTML的“Event Bubbling”，即事件浮升机制处理事件。Internet Explorer的DOM模型是HTML对象等级结构和事件处理机制。在DOM里，每一个HTML标识符都是一个DOM对象，而每一个对象都可以产生事先定义好的几个事件中的一个或几个。这样的一个事件首先会发生在事件所属的对象上，然后向上传播，传到对象所属的容器对象上。因此，事件浮升机制是事件捕捉机制的相反面。

   在Event Bubbling机制里，产生事件的对象首先会收到事件。然后。事件会依照对象的等级结构向上传播。

   如果要阻止事件继续向上传播，可以在事件链的任何一个节点上把cancelBubble性质设置成True即可。

   Internet Explorer浏览器几乎为所有的HTML标识符都提供了事件句柄。因此Internet Explorer不用其它的方法来捕获和释放事件。

 

 

 

实例：

1.抽象处理角色类

public abstract class AbstractHandler {
	private AbstractHandler nextHandler;

	public AbstractHandler getNextHandler() {
		return nextHandler;
	}

	public void setNextHandler(AbstractHandler nextHandler) {
		this.nextHandler = nextHandler;
	}

	public abstract void handleRequest();

}

 

2.具体处理角色类

public class ConcreteHandler extends AbstractHandler {

	private String name;

	public ConcreteHandler(String name) {
		this.name = name;
	}

	@Override
	public void handleRequest() {
		if (null != this.getNextHandler()) {
			System.out.println("This is " + name + " , next is " + ((ConcreteHandler) super.getNextHandler()).name);
			this.getNextHandler().handleRequest();
		} else {
			System.out.println("Last is " + this.name);
		}
	}

}

 

3.调用测试

public class Test {
	public static void main(String[] args) {
		ConcreteHandler handler1 = new ConcreteHandler("一 ");
		ConcreteHandler handler2 = new ConcreteHandler("二 ");
		ConcreteHandler handler3 = new ConcreteHandler("三 ");
		ConcreteHandler handler4 = new ConcreteHandler("四 ");
		ConcreteHandler handler5 = new ConcreteHandler("五 ");

		handler1.setNextHandler(handler5);
		handler5.setNextHandler(handler3);
		handler3.setNextHandler(handler2);
		handler2.setNextHandler(handler4);

		handler1.handleRequest();
	}
}