由于责任链大多数都是不纯的情况,本案例中,只要校验失败就直接返回,不继续处理接下去责任链中的其他校验逻辑了,故而出现如果某个部分逻辑是要由多个校验器组成一个整理的校验逻辑的话,则此责任链模式则显现出了它的不足之处了。(责任链模式的具体运用以及原理请参见笔者github wiki 2 责任链模式 )
关于接口适配器模式原理以及使用场景请参见笔者github wiki 12 适配器模式 。
事例代码请参见工程 design-patterns-business
中的 defaultmethod
包下的代码。
default medthod default
用来扩展已有的接口,在对已有接口的使用不产生任何影响的情况下,添加扩展。
比如我们已经投入使用的接口需要拓展一个新的方法,在Java8以前,如果为一个使用的接口增加一个新方法,则我们必须在所有实现类中添加该方法的实现,否则编译会出现异常。如果实现类数量少并且我们有权限修改,可能会工作量相对较少。如果实现类比较多或者我们没有权限修改实现类源代码,这样可能就比较麻烦。而默认方法则解决了这个问题,它提供了一个实现,当没有显示提供其他实现时就采用这个实现,这样新添加的方法将不会破坏现有代码。
默认方法的另一个优势是该方法是可选的,子类可以根据不同的需求Override默认实现。
例如,我们定义一个集合接口,其中有增、删、改等操作。如果我们的实现类90%都是以数组保存数据,那么我们可以定义针对这些方法给出默认实现,而对于其他非数组集合或者有其他类似业务,可以选择性复写接口中默认方法。
”类优先” 原则
接口冲突原则
由于系统业务需求的变更,目前有两种业务需求,
根据第2节的改进方式可以知道,我们有两种方式改进以上逻辑。
代码参见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); } ... }
局限性比较多。
代码参见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; } }
由此可见,其实此处的默认方法,就是上节中的适配器类的实现方式而已,而且对于后续的实现类而言,无须变动(针对不需要改动业务逻辑的类而言)。即使针对需要变动业务逻辑的类,也只是改动部分而已,而且不需要类型强制转换操作。避免了不必要的异常出现。
经过以上代码实现可以发现,默认接口实现有其非常明显的优势,即拥抱变化,扩展已有接口,向后兼容。
具体的测试代码可以参见相应版本的github单元测试代码即可。