资讯专栏INFORMATION COLUMN

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

suosuopuo / 660人阅读

摘要:责任链模式的具体运用以及原理请参见笔者责任链模式改进方式引入适配器模式关于接口适配器模式原理以及使用场景请参见笔者适配器模式。

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 逻辑梳理

由于系统业务需求的变更,目前有两种业务需求,

一种就是按照原来的文件上传需求,上传过程中需要校验操作,只要校验失败了,就直接返回失败信息,整个文件都不需要做处理了。(参见之前的文章 Java设计模式综合运用(门面+模版方法+责任链+策略))

另一种就是校验的逻辑都一样,但是如果校验失败的情况,需要继续往下执行,记录一下失败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 {

    /**
     * 需要引入责任链的时候,则采用此方法
     * @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  {

    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;
    }
}

而且,因为适配器类中的参数都是RequestDetailRequestFile类,故而子类可能需要做强制转换操作,如:

@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 {

    /**
     * 需要引入责任链的时候,则采用此方法
     * @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单元测试代码即可。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/74578.html

相关文章

  • Java 设计模式综合运用(门面+模版方法+责任+策略+工厂方法)

    摘要:注解方式优点使用注解方式可以极大的减少使用模版方法模式带来的扩展时需要继承模版类的弊端,工厂注解的方式可以无需关心其他业务类的实现,而且减少了类膨胀的风险。 在上一篇文章Java设计模式综合运用(门面+模版方法+责任链+策略)中,笔者写了一篇门面模式、模版方法、责任链跟策略模式的综合运用的事例文章,但是后来笔者发现,在实现策略模式的实现上,发现了一个弊端:那就是如果在后续业务发展中,需...

    Yuanf 评论0 收藏0
  • Java设计模式综合运用(门面+模版方法+责任+策略)

    摘要:此案例中,门面类为,然后各个门面方法的参数均为抽象类,通过决定调用中的哪个子类。抽象类持有类的对象,并且实现累的一个接口是为了容器启动完成的时候自动把相应的校验器加入到校验器链中。 引言:很久没有更新了,主要是工作忙。最近,工作中一个子系统升级,把之前不易扩展的缺点给改进了一下,主要是运用了几个设计模式进行稍微改造了一下。本文也同步发布至简书,地址: https://www.jians...

    刘东 评论0 收藏0
  • 工厂模式管理多个以太坊solidity智能合约

    摘要:在新智能合约的构造函数中,将引用我们的合约工厂的地址。以太坊,主要是针对工程师使用进行区块链以太坊开发的详解。以太坊入门教程,主要介绍智能合约与应用开发,适合入门。这里是原文用工厂模式管理多个智能合约 我们写了一份小的计算合约作为Hello World。如果我们可以创建一个允许用户创建自己的计数器的合约怎么办? showImg(https://segmentfault.com/img/...

    leone 评论0 收藏0
  • 又被面试官问设计模式了,我真的是

    摘要:面试官要不你来手写下单例模式呗候选者单例模式一般会有好几种写法候选者饿汉式简单懒汉式在方法声明时加锁双重检验加锁进阶懒汉式静态内部类优雅懒汉式枚举候选者所谓饿汉式指的就是还没被用到,就直接初始化了对象。面试官:我看你的简历写着熟悉常见的设计模式,要不你来简单聊聊你熟悉哪几个吧?候选者:常见的工厂模式、代理模式、模板方法模式、责任链模式、单例模式、包装设计模式、策略模式等都是有所了解的候选者:...

    不知名网友 评论0 收藏0

发表评论

0条评论

suosuopuo

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<