【行为型】职责链模式

装饰模式实际上很像一条单链表，每次装饰就是增加一个结点，增加一个结点以后这个对象就有了新的功能。设计模式中还有一种类似单链表的模式，职责链模式。

假设一个情景：学生可以申请请假，这个申请交由负责的辅导员，辅导员能批3 天以内典型的假期。如果不满足条件就交给年级主任，年级主任能够批1 个星期以内的假期，如果超过1 个星期的就得交给学院批，由学院来决定行不行。如图：

 

 

假设现在让你在一个教学系统中设计上面这个业务，应该如何设计好？

这样子，让学生自己判断，3 天的找辅导员，7 天的找主任……

 

 

那么可以用代码这样子实现：

这是辅导员类：

//辅导员是个老师
public class Teacher {
	
	public static void manageRequest(String requestContent, int days) {
		if (days <= 3) {
			if (requestContent == "病假") {
				System.out.println("辅导员：好吧同意了");
			} else if (requestContent == "产假") {
				System.out.println("辅导员：好吧同意了");
			} else {
				System.out.println("辅导员：不行这个我做不了主");
			}
		} else {
			System.out.println("辅导员：不行，超过3天了");
		}
	}
	
}

 

接下来的是主任类和学院类，跟上面辅导员类差不多：

 

//主任的英文翻译居然是Chairman
public class Chairman {
	
	public static void manageRequest(String requestContent, int days) {
		if (days <= 7 && days > 3) {
			if (requestContent == "病假") {
				System.out.println("主任：好吧同意了");
			} else if (requestContent == "产假") {
				System.out.println("主任：好吧同意了");
			} else if (requestContent == "事假") {
				System.out.println("主任：好吧同意了");
			} else {
				System.out.println("主任：不行这个我做不了主");
			}
		} else {
			System.out.println("主任：不行啊这不是我的职责范围");
		}
	}
}

// 这是学院
public class College {
	
	public static void manageRequest(String requestContent, int days) {
		if (days > 7) {
			if (requestContent == "病假") {
				System.out.println("学院：好吧同意了");
			} else if (requestContent == "产假") {
				System.out.println("学院：好吧同意了");
			} else if (requestContent == "事假") {
				System.out.println("学院：好吧同意了");
			} else if (requestContent == "打工") {
				System.out.println("学院：不行！");
			}
		} else {
			System.out.println("学院：不行啊这不是我的职责范围");
		}
	}
}

 

接下来是学生，学生先判断应该问谁，然后发出请求：

 

public class Student {
	
	// 学生发出请求
	public void sendRequest(String requestContent, int days) {
		System.out.print("已经发出申请......结果是..........");
		if (days <= 3) {
			Teacher.manageRequest(requestContent, days);
		} else if (days <= 7) {
			Chairman.manageRequest(requestContent, days);
		} else {
			College.manageRequest(requestContent, days);
		}
	}
	
}

 

场景：

 

         // 场景
         public static void main(String[] args) {
                   Student student = new Student();
                   student.sendRequest(" 病假", 2);
         } 

 

运行一下，如下：

已经发出申请...... 结果是.......... 辅导员：好吧同意了

 

 

这样子设计好吗？不好，代码不健壮。

如果我现在要申请2 天的事假，按照判断我应该交给Teacher ，但是Teacher 说他处理不了这样的事情，那就结束了吗？事实上就应该转交给Chairman 处理。这时候会想，我们把sendRequest() 方法加多一层判断不就行了吗？这就耦合了，另一方面，如果每个负责人的职责经常变化，那是不是得经常修改sendRequest() 和相应的负责人的源代码？单一职责设计原则约定好只能有一个原因可以引起类的变化，这就不符合单一职责原则，而且也不符合开闭原则。其次在一个方法中有大量的逻辑判断也显得代码臃肿，可读性差。

这里介绍职责链设计模式。作为一种行为模式，它是为了使多个对象都有机会处理请求，尽可能的避免请求者和处理者之间的耦合，而是让请求者只负责发送，处理者接受以后处理请求，如果不能处理就交给下一个处理者，直到有一个对象可以处理它。这时候处理者形成一条链表用于传递请求。

按照职责链模式我们修改学生发送请求的流程图。

 

 

改成这样以后，1 ）首先学生只要把请求发给辅导员就行了，辅导员如果处理不了就交给上一级，这时候学生类知道的东西很少，这就符合迪米特设计原则了。2 ）要增加多逻辑关系很容易，只要修改对应的负责人就行，不用修改发送请求的学生类，而且，要加入多一个负责人也很简单，只要扩展多一个类就行，耦合变低，相对来说更符合开闭原则。3 ）将各自的职责分开，学生不用处理关于负责人逻辑判断的东西，符合单一职责的原则。之后负责人方面要怎么修改，都不用修改学生类。

下面是重新修改的源代码：

处理者的抽象类：

 

//定义处理者的抽象类
public abstract class Handler {
	
	private Handler nextHandler;// 如果本对象不能处理请求，下一个处理者就是nextHandler
	
	// 判断是否能够处理这个请求
	protected abstract boolean judge(String request, int days);
	
	// 处理这个请求
	protected abstract boolean manage(String request, int days);
	
	public final void handle(String request, int days) {
		if (judge(request, days) == true) {// 可以处理这个请求
			manage(request, days);
		} else {// 不可以的话就交给下一个处理者
			if (nextHandler != null) {// 如果有下一个处理者，就交给它
				nextHandler.handle(request, days);
			} else {// 没有的话就终结
				System.out.println("没有后继者可以处理请求");
			}
		}
	}
	
}

 

修改3 个负责人类，如下：

 

//辅导员是个老师
public class Teacher extends Handler {
	
	@Override
	protected boolean judge(String request, int days) {
		if (days <= 3 && (request == "病假" || request == "产假")) {
			return true;
		}
		return false;
	}
	
	@Override
	protected void manage(String request, int days) {
		System.out.println("辅导员：好吧同意了");
	}
	
}

 

//主任的英文翻译居然是Chairman
public class Chairman extends Handler {
	
	@Override
	protected boolean judge(String request, int days) {
		if (days <= 7 && days > 3
				&& (request == "病假" || request == "产假" || request == "事假")) {
			return true;
		}
		return false;
	}
	
	@Override
	protected void manage(String request, int days) {
		System.out.println("主任：好吧同意了");
	}
	
}

 

// 这是学院类
public class College extends Handler {
	
	@Override
	protected boolean judge(String request, int days) {
		if (days > 7
				&& (request == "病假" || request == "产假" || request == "事假" || request == "打工")) {
			return true;
		}
		return false;
	}
	
	@Override
	protected void manage(String request, int days) {
		if (request == "打工") {
			System.out.println("学院：不行！");
			return;
		}
		System.out.println("主任：好吧同意了");
	}
	
}

 

以下是学生类，方法名未变，内部组装职责链过程在实际应用中可以优化：

 

public class Student {
	
	// 学生发出请求
	public void sendRequest(String requestContent, int days) {
		// 下面3行是建立3个负责人对象，实际开发应用中，这些可以用工厂模式自动封装好，不必每次都要组装
		Handler myTeacher = new Teacher();
		Handler myChairman = new Chairman();
		Handler myCollege = new College();
		// 以下2行将他们的责任关系串成链
		myTeacher.setNextHandler(myChairman);
		myChairman.setNextHandler(myCollege);
		System.out.print("已经发出申请......结果是..........");
		myTeacher.handle(requestContent, days);
	}
	
}

 

下面是场景，跟之前的一样：

 

         // 场景
         public static void main(String[] args) {
                   Student student = new Student();// 建立一个学生，他即将发送请求
                   student.sendRequest(" 病假", 5);
         } 

 

运行结果如下：

已经发出申请...... 结果是.......... 主任：好吧同意了

 

 

下面给出UML 设计图：

 

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

具体处理者(ConcreteHandler) 角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。