-
古代妇女的枷锁——"三从四德"
这里"三从"是指"未嫁从父、既嫁从夫、夫死从子"。举例来说，如果一位女性要出去逛街，在出嫁之前要得到父亲的同意，出嫁后得到丈夫的同意，丈夫不在了就得听儿子的同意。作为父亲、丈夫和儿子，只有两种选择：要不承担责任，要不就让他请示下一个人，下面我们看程序如何来实现这个过程，类图16-1如下:
类图很简单，IHander是三个有决策权对象的接口，IWomen是女性的代码，代码如下:
public interface IWomen {
//获得个人状况
public int getType();
//获得个人请示
public String getRequest();
}
一个方法是知道当前的个人状况getType，另一个方法getRequest是要请示的内容，其实现类代码如下:
public class Women implements IWomen {
/**
* 通过type来描述妇女的个人状况
* 1.--未出嫁
* 2.--出嫁
* 3.--夫死
*/
private int type = 0;
private String request = "";
public Women(int type,String request){
this.type = type;
this.request = request;
}
@Override
public int getType() {
return this.type;
}
@Override
public String getRequest() {
return this.request;
}
}
从整个设计上分析，有处理权的人才是设计的核心，他们是要处理这些请求的，我们来看有处理权的人员接口IHandler，代码如下:
public interface IHandler {
public void HandleMessage(IWomen women);
}
有处理权的人对请求进行处理，分别有三个实现类，其实现代码如下:
public class Father implements IHandler {
@Override
public void HandleMessage(IWomen women) {
System.out.println("女儿的请示是:"+women.getRequest());
System.out.println("父亲的回答是:同意");
}
}
public class Husband implements IHandler {
@Override
public void HandleMessage(IWomen women) {
System.out.println("妻子的请示是:"+women.getRequest());
System.out.println("丈夫的回答是:同意");
}
}
public class Son implements IHandler {
@Override
public void HandleMessage(IWomen women) {
System.out.println("母亲的请示是:"+women.getRequest());
System.out.println("儿子的回答是:同意");
}
}
我们在来模拟一下古代妇女出去逛街是如何请示的:
public class Client {
public static void main(String[] args) {
Random rand = new Random();
ArrayList<IWomen> arrayList = new ArrayList<>();
for(int i=0;i<5;i++){
arrayList.add(new Women(rand.nextInt(4),"shopping"));
}
//定义三个请示对象
IHandler father = new Father();
IHandler husband = new Husband();
IHandler son = new Son();
for(IWomen women : arrayList){
if(women.getType() == 1){
System.out.println("---女儿向父亲请示---");
father.HandleMessage(women);
}else if(women.getType() == 2){
System.out.println("---妻子向丈夫请示---");
husband.HandleMessage(women);
}else if(women.getType() == 3){
System.out.println("---母亲向儿子请示---");
son.HandleMessage(women);
}else{
//暂时什么也不做
}
}
}
}
虽然这段代码大致变现出了我们要的效果，但是这段代码设计上明显有问题：
- 职责界定不清晰
对女儿提出的请示，Handler类应该知道是不是需要自己处理，而不是在Client中进行组装出来 - 代码臃肿
在Client中写了if...else的判断条件，而且随着能处理该类型请示的人员越多，判断就越多 - 耦合过重
我们要根据Women的type来决定使用IHandler的哪个实现类来处理，如果IHandler的实现类继续扩展怎么办，就只能修改Client类，与开闭原则违背
既然有这么多问题，我们要想办法来解决这些问题，我们先来分析一下需求，女性提出一个请示，必然要获得一个答复，而且是必然有一个唯一的处理人给出唯一的答复，重新设计，我们可以抽象成这样一个结构，将请求依次传递下去，知道有责任人处理请求，如图:
16-2
每个责任人节点有两个选择:要么承担责任，做出回应；要么把请求转发到后续环节（这个链式的思想在很多地方都有应用，比如说过滤器，也是一层层的传递下去，只不过可能每一层过滤器都会对请求做处理；jvm加载类的时候也是用到了这样链式思想的）
我们来看一下类图16-3:
16-3
从类图上看，三个实现类只要实现构造函数和父类中的抽象方法response就可以了，具体由谁处理请求，都已经转移到了Handler抽象类中，代码如下:
public abstract class Handler {
public final static int FATHER_LEVEL_REQUEST = 1;
public final static int HUSBAND_LEVEL_REQUEST = 2;
public final static int SON_LEVEL_REQUEST = 3;
//能处理的级别
private int level = 0;
//责任传递，下一个责任人是谁
private Handler nextHandler;
public Handler(int level){
this.level = level;
}
public final void HandleMessage(IWomen women){
if(women.getType() == this.level){
this.response(women);
}else{
if(this.nextHandler != null){
this.nextHandler.HandleMessage(women);
}else{
System.out.println("没地方请示了，按不同意处理");
}
}
}
public void setNext(Handler handler){
this.nextHandler = handler;
}
protected abstract void response(IWomen women);
}
这个地方还用到了模板方法模式，就是HandleMessage属于模板方法，用来判断请求的处理归于那个节点，基本方法response需要各个实现类实现，每个实现类只要实现两个职责：一是定义自己能够处理的等级级别；二是对请求作出回应.我们首先来看各个节点的实现，代码如下:
public class Father extends Handler {
public Father(){
super(Handler.FATHER_LEVEL_REQUEST);
}
@Override
protected void response(IWomen women) {
System.out.println("女儿的请示是:"+women.getRequest());
System.out.println("父亲的回答是:同意");
}
}
public class Husband extends Handler {
public Husband() {
super(Handler.HUSBAND_LEVEL_REQUEST);
}
@Override
protected void response(IWomen women) {
System.out.println("妻子的请示是:"+women.getRequest());
System.out.println("丈夫的回答是:同意");
}
}
public class Son extends Handler {
public Son() {
super(Handler.SON_LEVEL_REQUEST);
}
@Override
protected void response(IWomen women) {
System.out.println("母亲的请示是:"+women.getRequest());
System.out.println("儿子的回答是:同意");
}
}
处理请求的模块完了，看一下women类，接口没有变化，看一下实现类代码如下:
public class Women implements IWomen {
/**
* 通过type来描述妇女的个人状况
* 1.--未出嫁
* 2.--出嫁
* 3.--夫死
*/
private int type = 0;
private String request = "";
public Women(int type,String request){
this.type = type;
switch (this.type){
case 1:
this.request = "女儿的请求是:"+request;
break;
case 2:
this.request = "妻子的请求是:"+request;
break;
case 3:
this.request = "母亲的请求是:"+request;
break;
}
}
@Override
public int getType() {
return this.type;
}
@Override
public String getRequest() {
return this.request;
}
}
场景类模拟一下，代码如下:
public class Client {
public static void main(String[] args) {
Random rand = new Random();
ArrayList<IWomen> arrayList = new ArrayList<>();
for(int i=0;i<5;i++){
arrayList.add(new Women(rand.nextInt(4),"shopping"));
}
//定义三个请示对象
Handler father = new Father();
Handler husband = new Husband();
Handler son = new Son();
father.setNext(husband);
husband.setNext(son);
for(IWomen women : arrayList){
father.handleMessage(women);
}
}
}
业务调用类Client也不用去做判断到底需要谁去处理，而且Handler抽象类的子类可以继续增加下去，只需要扩展传递链而已，调用类可以不用了解变化过程，甚至是谁在处理这个请求都不用知道。（看到这里，有一种很熟悉的感觉，有没有觉得命令模式和这个责任链模式非常相像，都是发出请求（命令）交给相关的责任（接收）类去处理，但是责任链是不清楚请求应该有谁去处理，只能一级级往后传递；命令模式中虽然高层模块不知道也不用知道接收者是谁，但是命令类中就已经将接收者封装好了；而且这个请求是不是也很像发命令，那我们是不是也可以将这些请求封装为命令，只是不清楚命令的接收者是谁，有责任链中的责任类自己去处理。有没有感觉设计模式中好多模式之间是有共同点的，例如工厂模式和建造者模式）
-
责任链模式的定义
责任链模式的定义如下:
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.Chain the receving objects and pass the request along the chain until an object handles it.(使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。)
责任链模式的重点是在“链”上，由一条链去处理相似的请求在链中决定谁来处理这个请求，并返回相应的结果，其通用类图如图16-4所示:
责任链是有多个处理者ConcreteHandler组成的，我们先看看抽象Handler类，代码如下:
public abstract class Handler {
//下一个处理节点
private Handler nextHandler;
public final Response handleMessage(Request request){
Response response = null;
if(this.getHandlerLevel().equals(request.getRquestLevel())){
response = this.echo(request);
}else{
if(this.nextHandler != null){
response = this.nextHandler.handleMessage(request);
}else {
//没有适当的处理类，业务自行处理
}
}
return response;
}
protected void setNextHandler(Handler handler){
this.nextHandler = handler;
}
protected abstract Response echo(Request request);
protected abstract Level getHandlerLevel();
}
抽象的处理者实现三个职责：一是定义一个请求的处理方法handleMessaage，唯一对外开放的方法；二是定义一个链的编排方法setNextHandler,设置下一个处理者；三是定义了具体的请求者必须实现的两个方法：定义自己能够处理的级别getHandlerLevel和具体处理任务echo。
其他的相关的类代码就不在这里写了，重点就是这个hanlder类，注意看handleMessage用了final关键字，这个就是模板方法。在实际应用中，我们可以封装一个责任模式的类，用来编排链的顺序等，然后返回第一个处理者，简化高层模块，减少模块间的耦合。
-
责任链模式的应用
3.1 责任链模式的优点
责任链模式非常显著的优点就是将请求和处理分开。请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌，两者解耦，提高系统的灵活性。
3.2 责任链模式的缺点
责任链有两个非常显著的缺点：一是性能问题，每个请求都是从链头遍历到链尾，特别是在链比较长的时候，性能是一个非常大的问题。二是调试不方便，特别是链比较长，由于采用了类似递归的方式，调用的时候逻辑可能比较复杂。
3.3责任链的注意事项
链中节点数量需要控制，避免出现超长链的情况，一般的做法是在Handler中设置一个最大节点数，在setNext中判断是否已经超过其阀值，避免无意识的破坏系统性能。
4.#####最佳实践
在例子中和通用源码中Handler是抽象类，融合了模板方法模式，每个实现类只要实现两个方法：处理请求的具体逻辑和获得处理级别的方法（判断是否在本职责类中处理请求），想想单一职责和迪米特法则，通过融合模板方法模式，各个实现类只要关注自己的业务逻辑就成了，至于职责的判断就给父类处理了，符合单一职责原则，子类的实现非常简单，责任链的建立也是非常灵活。
内容来自《设计模式之禅》
