Java设计模式综合运用(责任链模式进阶)

1 责任链模式现存缺点

因为责任链大多数都是不纯的状况，本案例中，只要校验失败就直接返回，不继续处理接下去责任链中的其余校验逻辑了，故而出现若是某个部分逻辑是要由多个校验器组成一个整理的校验逻辑的话，则此责任链模式则显现出了它的不足之处了。（责任链模式的具体运用以及原理请参见笔者github wiki 2 责任链模式）

2 改进方式

2.1 引入适配器模式

关于接口适配器模式原理以及使用场景请参见笔者github wiki 12 适配器模式 。

2.2 引入接口默认方法

事例代码请参见工程 design-patterns-business中的 defaultmethod包下的代码。

2.2.1 概念

• java8引入了一个 default medthod
• 使用 default 关键字
• Spring 4.2支持加载在默认方法里声明的bean

2.2.2 优势

• 用来扩展已有的接口，在对已有接口的使用不产生任何影响的状况下，添加扩展。

  好比咱们已经投入使用的接口须要拓展一个新的方法，在Java8之前，若是为一个使用的接口增长一个新方法，则咱们必须在全部实现类中添加该方法的实现，不然编译会出现异常。若是实现类数量少而且咱们有权限修改，可能会工做量相对较少。若是实现类比较多或者咱们没有权限修改实现类源代码，这样可能就比较麻烦。而默认方法则解决了这个问题，它提供了一个实现，当没有显示提供其余实现时就采用这个实现，这样新添加的方法将不会破坏现有代码。

• 默认方法的另外一个优点是该方法是可选的，子类能够根据不一样的需求Override默认实现。

  例如，咱们定义一个集合接口，其中有增、删、改等操做。若是咱们的实现类90%都是以数组保存数据，那么咱们能够定义针对这些方法给出默认实现，而对于其余非数组集合或者有其余相似业务，能够选择性复写接口中默认方法。

2.2.3 使用原则

• ”类优先” 原则

  • 若一个接口中定义了一个默认方法，而另一个父类或接口中又定义了一个同名的方法时选择父类中的方法：若是一个父类提供了具体的实现，那么接口中具备相同名称和参数的默认方法会被忽略。

• 接口冲突原则

  • 若是一个父接口提供一个默认方法，而另外一个接口也提供了一个具备相同名称和参数列表的方法（无论方法是不是默认方法），那么必须覆盖该方法来解决冲突。

4.3 项目演示

3.1 逻辑梳理

因为系统业务需求的变动，目前有两种业务需求，

1. 一种就是按照原来的文件上传需求，上传过程当中须要校验操做，只要校验失败了，就直接返回失败信息，整个文件都不须要作处理了。（参见以前的文章 Java设计模式综合运用(门面+模版方法+责任链+策略)）
2. 另外一种就是校验的逻辑都同样，可是若是校验失败的状况，须要继续往下执行，记录一下失败id便可，即须要把失败的记录也保存到数据库中，好比约束字段不符合约束规则的状况，则把此字段置空，而后继续执行其余校验器逻辑便可。（本节须要讨论的问题）

3.2 实现方案

根据第2节的改进方式能够知道，咱们有两种方式改进以上逻辑。

3.2.1 采用适配器模式

代码参见2.1版本的，地址为： https://github.com/landy8530/...

若采用适配器模式，此处咱们会采用接口适配器模式。

接口须要多增长一个不用链式调用的校验方法，定义以下，

/**
 * 业务校验统一接口,增长了接口的默认方法实现，这样能够更加方便且自由选择实现接口的哪些方法。
 * @author landyl
 * @create 10:32 AM 05/09/2018
 * @version 2.0
 * @since 1.0
 */
public interface Validator<R extends RequestDetail,F extends RequestFile> {

    /**
     * 须要引入责任链的时候，则采用此方法
     * @param detail
     * @param chain
     * @return
     * @throws BusinessValidationException
     */
    String doValidate(R detail, F file, ValidatorChain chain) throws BusinessValidationException;

    /**
     * 不须要责任链的时候，则能够直接调用此方法的实现便可
     * @param detail
     * @return
     * @throws BusinessValidationException
     */
    boolean doValidate(R detail, F file) throws BusinessValidationException;
}

适配器类定义以下抽象类，

/**
 * @author: landy
 * @date: 2019/5/19 14:48
 * @description:
 */
public abstract class ValidatorAdapter implements Validator<RequestDetail, RequestFile>  {

    public String doValidate(RequestDetail detail, RequestFile file, ValidatorChain chain) throws BusinessValidationException {
        boolean isValid = this.doValidate(detail, file);
        //校验失败了，就直接返回
        if(!isValid) {
            if(detail.getValidationResult() != null) {
                return detail.getValidationResult().getResultMsg();
            }
        }
        //不然往责任链中下一个校验器进行处理
        return chain.doValidate(detail, file);
    }

    @Override
    public boolean doValidate(RequestDetail detail, RequestFile file) throws BusinessValidationException {
        return true;
    }
}

如此一来，由于增长了原有接口中的方法，则须要在每一个实现类中都增长一个实现方法，虽然有以上的适配器类，可是也要把以前实现接口改成继承该适配器类，即 ValidatorAdapter 类。好比，

/**
 * @author landyl
 * @create 2:57 PM 05/09/2018
 */
@Component(ValidatorConstants.BEAN_NAME_CUSTOMER_IS_ACTIVE)
public class IsActiveValidator extends ValidatorAdapter {

    @Override
    public boolean doValidate(RequestDetail detail, RequestFile file) throws BusinessValidationException {
        if (StringUtils.isNotEmpty(detail.getIsActive())
                && !"0".equals(detail.getIsActive())
                && !"1".equals(detail.getIsActive())) {
            String result = "An invalid Is Active setting was provided. Accepted Value(s): 0, 1 (0 = No; 1 = Yes).";
            detail.bindValidationResult(Constants.INVALID_IS_ACTIVE,result);
            return false;
        }
        return true;
    }
}

并且，由于适配器类中的参数都是RequestDetail 和 RequestFile类，故而子类可能须要作强制转换操做，如：

@Component(ValidatorConstants.BEAN_NAME_CUSTOMER_BUSINESS_LINE)
public class BusinessLineValidator extends ValidatorAdapter {

    public String doValidate(RequestDetail detail, RequestFile file, ValidatorChain chain) throws BusinessValidationException {
        if(detail instanceof CustomerRequestDetail) {
            CustomerRequestDetail crd = (CustomerRequestDetail)detail;
            String result = validateBusinessLineLogic(crd);
            if(!Constants.VALID.equals(result)){
                return result;
            }
        }
        return chain.doValidate(detail,file);
    }
    ...

}

局限性比较多。

3.2.2 采用接口默认方法

代码参见2.0版本，地址为： https://github.com/landy8530/... ，后续也会merge到master版本。

接口定义以下，采用默认方法实现，

/**
 * 业务校验统一接口,增长了接口的默认方法实现，这样能够更加方便且自由选择实现接口的哪些方法。
 * @author landyl
 * @create 10:32 AM 05/09/2018
 * @version 2.0
 * @since 1.0
 */
public interface Validator<R extends RequestDetail,F extends RequestFile> {

    /**
     * 须要引入责任链的时候，则采用此方法
     * @param detail
     * @param chain
     * @return
     * @throws BusinessValidationException
     */
    default String doValidate(R detail, F file, ValidatorChain chain) throws BusinessValidationException {
        boolean isValid = this.doValidate(detail, file);
        //校验失败了，就直接返回
        if(!isValid) {
            if(detail.getValidationResult() != null) {
                return detail.getValidationResult().getResultMsg();
            }
        }
        //不然往责任链中下一个校验器进行处理
        return chain.doValidate(detail, file);
    }

    /**
     * 不须要责任链的时候，则能够直接调用此方法的实现便可
     * @param detail
     * @return
     * @throws BusinessValidationException
     */
    default boolean doValidate(R detail, F file) throws BusinessValidationException { return true; }

}

因而可知，其实此处的默认方法，就是上节中的适配器类的实现方式而已，并且对于后续的实现类而言，无须变更（针对不须要改动业务逻辑的类而言）。即便针对须要变更业务逻辑的类，也只是改动部分而已，并且不须要类型强制转换操做。避免了没必要要的异常出现。

3.2.3 方案对比

通过以上代码实现能够发现，默认接口实现有其很是明显的优点，即拥抱变化，扩展已有接口，向后兼容。

3.3 逻辑测试

具体的测试代码能够参见相应版本的github单元测试代码便可。