Java设计模式----职责链模式(Responsibility Chain)

1.什么是职责链模式

“一对二”，“过”，“过”……这声音熟悉吗？你会想到什么？对！纸牌。在类似“斗地主”这样的纸牌游戏中，某人出牌给他的下家，下家看看手中的牌，如果要不起上家的牌则将出牌请求再转发给他的下家，其下家再进行判断。一个循环下来，如果其他人都要不起该牌，则最初的出牌者可以打出新的牌。在这个过程中，牌作为一个请求沿着一条链在传递，每一位纸牌的玩家都可以处理该请求。在设计模式中，我们也有一种专门用于处理这种请求链式传递的模式，它就是本章将要介绍的职责链模式。

2.实现方式

(1) 纯的职责链模式

一个纯的职责链模式要求一个具体处理者对象只能在两个行为中选择一个：要么承担全部责任，要么将责任推给下家，不允许出现某一个具体处理者对象在承担了一部分或全部责任后又将责任向下传递的情况。而且在纯的职责链模式中，要求一个请求必须被某一个处理者对象所接收，不能出现某个请求未被任何一个处理者对象处理的情况。在下面的请假实例中应用的是纯的职责链模式。例子：Sunny软件公司的OA系统需要提供一个假条审批模块：如果员工请假天数小于3天，主任可以审批该假条；如果员工请假天数大于等于3天，小于10天，经理可以审批；如果员工请假天数大于等于10天，小于30天，总经理可以审批；如果超过30天，总经理也不能审批，提示相应的拒绝信息。试用职责链模式设计该假条审批模块。分析：主任->经理->总经理构成了一条链式处理

Leave.java

package cn.limbo.test;

import cn.limbo.design_patterns.responsibility_chain.Approver;
import cn.limbo.design_patterns.responsibility_chain.Leave;
import cn.limbo.design_patterns.responsibility_chain.concrete_approver.Director;
import cn.limbo.design_patterns.responsibility_chain.concrete_approver.MainManager;
import cn.limbo.design_patterns.responsibility_chain.concrete_approver.Manager;
import org.junit.Test;

/**
 * 请假类
 * Created by limbo on 2016/12/11.
 */
public class ResponsibilityTest {

	@Test
	public void show(){

		Leave leave = new Leave("wyh",40);
		Approver director, manager,mainManager;
		director = new Director("主任");
		manager = new Manager("经理");
		mainManager = new MainManager("总经理");

		director.setSuccessor(manager);
		manager.setSuccessor(mainManager);

		director.handleRequest(leave);

	}

}

Approver.java

package cn.limbo.design_patterns.responsibility_chain;

/**
 * 抽象类，审批者
 * Created by limbo on 2016/12/11.
 */
public abstract class Approver {

	protected Approver successor;
	protected String name;

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

	//设置后继者
	public void setSuccessor(Approver successor){
		this.successor = successor;
	}

	public abstract void handleRequest(Leave leave);
}

Director.java

package cn.limbo.design_patterns.responsibility_chain.concrete_approver;

import cn.limbo.design_patterns.responsibility_chain.Approver;
import cn.limbo.design_patterns.responsibility_chain.Leave;

/**
 * 主任
 * Created by limbo on 2016/12/11.
 */
public class Director extends Approver {


	public Director(String name) {
		super(name);
	}

	@Override
	public void handleRequest(Leave leave) {
		if (leave.getDays() <= 3) {
			System.out.println("主任处理了" + leave.getName() + "的请假");
			return ;
		}
		this.successor.handleRequest(leave);
	}


}

Manager.java

package cn.limbo.design_patterns.responsibility_chain.concrete_approver;

import cn.limbo.design_patterns.responsibility_chain.Approver;
import cn.limbo.design_patterns.responsibility_chain.Leave;

/**
 * 经理
 * Created by limbo on 2016/12/11.
 */
public class Manager extends Approver {

	public Manager(String name) {
		super(name);
	}

	@Override
	public void handleRequest(Leave leave) {
		if (leave.getDays() <= 10) {
			System.out.println("经理处理了" + leave.getName() + "的请假");
			return;
		}
		this.successor.handleRequest(leave);
	}
}

MainManager.java

package cn.limbo.design_patterns.responsibility_chain.concrete_approver;

import cn.limbo.design_patterns.responsibility_chain.Approver;
import cn.limbo.design_patterns.responsibility_chain.Leave;

/**
 * 总经理
 * Created by limbo on 2016/12/11.
 */
public class MainManager extends Approver {
	public MainManager(String name) {
		super(name);
	}

	@Override
	public void handleRequest(Leave leave) {
		if (leave.getDays() <= 30) {
			System.out.println("总经理处理了" + leave.getName() + "的请假");
		}else {
			System.out.println("该请假不能受理");
		}
	}
}

测试类：

package cn.limbo.test;

import cn.limbo.design_patterns.responsibility_chain.Approver;
import cn.limbo.design_patterns.responsibility_chain.Leave;
import cn.limbo.design_patterns.responsibility_chain.concrete_approver.Director;
import cn.limbo.design_patterns.responsibility_chain.concrete_approver.MainManager;
import cn.limbo.design_patterns.responsibility_chain.concrete_approver.Manager;
import org.junit.Test;

/**
 * 请假类
 * Created by limbo on 2016/12/11.
 */
public class ResponsibilityTest {

	@Test
	public void show(){

		Leave leave = new Leave("wyh",40);
		Approver director, manager,mainManager;
		director = new Director("主任");
		manager = new Manager("经理");
		mainManager = new MainManager("总经理");

		director.setSuccessor(manager);
		manager.setSuccessor(mainManager);

		director.handleRequest(leave);

	}

}

(2)不纯的职责链模式 

在一个不纯的职责链模式中允许某个请求被一个具体处理者部分处理后再向下传递，或者一个具体处理者处理完某请求后其后继处理者可以继续处理该请求，而且一个请求可以最终不被任何处理者对象所接收。Java AWT 1.0中的事件处理模型应用的是不纯的职责链模式，其基本原理如下：由于窗口组件（如按钮、文本框等）一般都位于容器组件中，因此当事件发生在某一个组件上时，先通过组件对象的handleEvent()方法将事件传递给相应的事件处理方法，该事件处理方法将处理此事件，然后决定是否将该事件向上一级容器组件传播；上级容器组件在接到事件之后可以继续处理此事件并决定是否继续向上级容器组件传播，如此反复，直到事件到达顶层容器组件为止；如果一直传到最顶层容器仍没有处理方法，则该事件不予处理。每一级组件在接收到事件时，都可以处理此事件，而不论此事件是否在上一级已得到处理，还存在事件未被处理的情况。显然，这就是不纯的职责链模式，早期的Java AWT事件模型(JDK 1.0及更早)中的这种事件处理机制又叫事件浮升(Event Bubbling)机制。从Java.1.1以后，JDK使用观察者模式代替职责链模式来处理事件。目前，在JavaScript中仍然可以使用这种事件浮升机制来进行事件处理。

3.优缺点

1.主要优点

(1) 职责链模式使得一个对象无须知道是其他哪一个对象处理其请求，对象仅需知道该请求会被处理即可，接收者和发送者都没有对方的明确信息，且链中的对象不需要知道链的结构，由客户端负责链的创建，降低了系统的耦合度。
(2) 请求处理对象仅需维持一个指向其后继者的引用，而不需要维持它对所有的候选处理者的引用，可简化对象的相互连接。
(3) 在给对象分派职责时，职责链可以给我们更多的灵活性，可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的职责。
(4) 在系统中增加一个新的具体请求处理者时无须修改原有系统的代码，只需要在客户端重新建链即可，从这一点来看是符合“开闭原则”的。

2.主要缺点

(1) 由于一个请求没有明确的接收者，那么就不能保证它一定会被处理，该请求可能一直到链的末端都得不到处理；一个请求也可能因职责链没有被正确配置而得不到处理。

(2) 对于比较长的职责链，请求的处理可能涉及到多个处理对象，系统性能将受到一定影响，而且在进行代码调试时不太方便。

(3) 如果建链不当，可能会造成循环调用，将导致系统陷入死循环。

4.适用场景

在以下情况下可以考虑使用职责链模式：

(1) 有多个对象可以处理同一个请求，具体哪个对象处理该请求待运行时刻再确定，客户端只需将请求提交到链上，而无须关心请求的处理对象是谁以及它是如何处理的。

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

(3) 可动态指定一组对象处理请求，客户端可以动态创建职责链来处理请求，还可以改变链中处理者之间的先后次序。