对老系统校验的改造设计

批单校验优化部分的改造基于可扩展，良好的可读性和可测试性的思路。基于这样的思路，我把校验分成了三部分。校验因子，校验规则，以及获取校验因子数据功能。校验因子以javabean的形式表述。校验规则根据校验因子做与或非的逻辑校验。数据获取功能通过对javabean做动态代理的方式插入。达到三个功能间的解耦！以期达到职责单一。从而得到一个可以对各个模块做单独测试的目的。
原始机制
原来的批单逻辑校验部分，各个页面通过调用统一的action url路径。在action层做所有的逻辑校验。校验逻辑混合在一个action方法中。校验逻辑之间没有明显划分。校验因子数据的获取与校验逻辑混合！这种方式在代码可读性和可扩展性都不强。



如果质押解质需求有所改变，需要根据另外一个校验因子做判断。那将会导致需要通读这全段代码，找到所有关于质押的校验，然后挨个条件。对于不懂质押需求的开发人员，做这件事相信风险是非常大的！同事，这些代码还被揉杂在其他诸如收付状态灯的校验当中。修改的复杂度在这种需求的不断变更中不断被拉高！

基于职责链于动态代理模式对校验逻辑的改造
优化设计如下：

1. 类设计




2. 类职责说明
a) Factor 做为一个因子接口的存在，里面只有对因子的get ，set方法
b) FactorBean 做为因子的具体实现。
c) validateHendler 作为一个校验的抽象类。是职责链模式的一部分
d) ValidateA实现了validateHendler ,同时它也继承了基类中的成员变量和该成员变量的设置值和获取值的方法！
e) InvocationHandler是jdk提供的一个接口，实现jdk动态代理必须实现的一个接口
f) FactorInvokerA 实现了invovationHandler接口，同时依赖了接口Factor，因此也就具有了对Factor设置值得能力。
3. 部分代码示例
a) 测试代码：


b) Factor接口代码


c) FactorBean代码


d) 校验抽象类代码


e) 打印校验类代码


f) 具体handler类代码


改造后获得的优势
外层调用不需要知道校验因子该如何设置，也不需要知道具体该如何校验，只用创建多个单一的校验类，以一个链的形式去做校验！彻底隔离了action于校验部分。

具体的校验类不需要知道因子应该如何获取，只需要调用代理就可以获得需要的因子，使得校验规则能够清晰展现。

获取因子的方法被封装到一个个的代理类中。方便扩展校验因子

由于各个类的职责单一，而且彻底脱离了action层，因此测试代码可以非常容易的编写。
当前改造方案的不足
设计一个Factor接口，主要是因为jdk提供的动态代理，只能对接口做代理。因为不想做过多的代码添加，另外考虑到往工程中添加额外的jra包，可能会导致jra版本不一致，以及jra之间的依赖风险。所以也没有采用spring的动态代理。

如果想要在保单验证或者其他验证部分服用该部分代码，只能通过在Factor中添加因子。将会导致Factor膨胀等问题。