设计模式-利用职责链模式消除if

本文是对职责链设计模式的应用（变种），所以假设读者已经掌握了职责链设计模式，职责链模式只会应景简介。

本文主要内容：

1. 需求（ShitCode）
2. 职责链模式简介
3. 设计理念
4. 代码演示（消除if）
5. 应用总结

一、需求（ShitCode）

package com.cnblogs.kmpp;
 
public class ShitCode {
 
    public void doSomething(ParameterObject parameterObject)
    {
        if (parameterObject != null)//判断输入参数是否为null
        {
            if (parameterObject.getId() > 0)//判断输入参数的ID是否大于0
            {
                int code = getCodeById(parameterObject.getId());//业务逻辑判断
                if (code > 0)
                {
                    //有可能还会有其他的判断
                    //do something vaild
                }
            }
        }
    }
 
    private int getCodeById(int id) {
        return 0;
    }
}

上面这段ShitCode很明显，有大量的if判断：在满足众多if后才去做具体的事情，上面ShitCode只有三个if，实际情况中有可能会更多。怎么办？

二、职责链模式简介

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

上图是职责链模式的经典类图。如果了解这个设计模式，上面定义中说到的链路（successor）是由ConcreteHandler在HandleRequest的时候按照某种逻辑来指定的。比如请假，经理和总监是两个不同的ConcreteHandler，hr设定当请假天数大于5天时，需要总监来处理，这个时候经理会设置自己的successor为总监，从而形成一个链路。

三、设计理念

再次回到ShitCode。仔细看看ShitCode可以抽象为：当条件1满足的时候再去判断条件2。。。一直到条件N不满足或者最后一个条件满足为止（没有successor）。这是一个递归的过程。

所以这个条件之间的调度是可以抽象出来，本文开始说了，本次的应用是对职责链设计模式的应用，是一个变种。因为这个条件之间的调度是可以抽象出来，所以这个调度是可以放在父类中进行执行，而无需在每一个ConcreteHandle执行。这点便是对本文对于职责链设计模式的修改点。

四、代码演示（消除if）

4.1 父类：定义算法骨架

验证器的抽象，递归调度条件验证器。

package com.cnblogs.kmpp;
 
public abstract class AbsctractValidator
{
    private AbsctractValidator validatorSuccessor;
 
    protected void setValidatorSuccessor(AbsctractValidator validatorSuccessor)//这个和经典的职责链模式一样，用于设置下一个
    {
        this.validatorSuccessor = validatorSuccessor;
    }
 
    public boolean validate(ParameterObject parameterObject)
    {
        boolean result=this.validateSelfLogic(parameterObject);//验证当前逻辑
        if(result)//当前逻辑满足
        {
            if(this.validatorSuccessor!=null)//有下一个验证器
            {
                return this.validatorSuccessor.validate(parameterObject);//继续验证
            }
        }
        return  result;//返回最终结果
    }
 
    public abstract boolean validateSelfLogic(ParameterObject parameterObject);
 
}

4.2 第一个条件参数验证的ConcreteValidator

只需实现自己的参数验证逻辑，无需关注其他事情

package com.cnblogs.kmpp;
 
public class ParameterValidator extends AbsctractValidator
{
    @Override
    public boolean validateSelfLogic(ParameterObject parameterObject)
    {
        System.out.println("in validator1");
        if(parameterObject==null)
        {
            System.out.println("parameterObject is null");
            return  false;
        }
        if(parameterObject.getId()<=0)
        {
            System.out.println("parameterObject.getId()<=0");
            return false;
        }
        return true;
    }
}

4.3 第二个业务逻辑验证的ConcreteValidator

只需实现自己的业务逻辑验证逻辑，无需关注其他事情

package com.cnblogs.kmpp;
 
public class BusinessLogicValidator extends AbsctractValidator
{
    @Override
    public boolean validateSelfLogic(ParameterObject parameterObject)
    {
        System.out.print("in validator2");
        int code=this.getCodeById(parameterObject.getId());
        if(code>0)
        {
            System.out.println("code>0");
            return  true;
        }
        return false;
    }
 
    private int getCodeById(int id)
    {
        return 0;
    }
}

当有新需求时候还可以继续扩展新的Validator。

4.4 Cient调用

package com.cnblogs.kmpp;
 
public class Client {
    public static void main(String args[])
    {
        ParameterValidator parameterValidator=new ParameterValidator();
        BusinessLogicValidator businessLogicValidator=new BusinessLogicValidator();
        parameterValidator.setValidatorSuccessor(businessLogicValidator);
        parameterValidator.validate(null);
    }
}

上面的代码中已经消除成功消除了if。且上面的代码BusinessLogicValidator是不会执行的，因为validate（null）。第一个ParameterValidator最后会返回false。

五、总结

本文主要说职责链模式，其实仔细看看上面用到的也是模版方法：父类定义算法骨架，子类实现部分逻辑。

在本文的设计中，AbstractValidator完整的定义了算法骨架以及调度的抽象，每一个ConcreteValidator只需要实现真正属于自己验证的逻辑，无需关注其他事情，满足单一职责原则，那当然也满足了Open-Close原则：

1. 每一个validator可以随便修改而不影响其他Validator
2. 可以继续继承AbstractValidator实现新的Validator

设计模式要活学活用，不要过于拘泥于格式。上面的设计其实还可以衍生出很多变种的。