查询列表需查询其它系统的数据拼装的重构案例

需求描述

目前在项目中有两个版本并行，一个A版本，一个B版本，由于A版本并未完全下线，而且A版本是基于业务状态流的，B版本是基于activiti的，并且数据结构是经过重新设计的，也有一个申请的入口，那么我们需要在B版本的每一个环节的待办列表尾部查询到A版本的申请单数据并进行处理。

当前的实现方式

程序员拿到这个需求后理所当然的认为，我在每个节点的查询的时候进行处理，并且成功的实现了功能。

实现方式解析

当我进行代码QC的时候我的内心是崩溃的，因为我的原来设计的待办中根据待办编码的列表进行配置的（下次有机会写一下这个设计），所以我把代码一看，里面增加了许多的代码，里面有根据不同待办编码的进行判断，由于涉及到信息安全，下面伪代码代替.

if(环节1)
    私有方法1
else if (环节2)
    私有方法1
......
end if

不得不说还有点觉悟，知道把分开方法，因为原来设计的代办查询里只有一方法，现在会随着环节的增加增加更多的方法。这样带来如下问题：

• 这个类的代码十分的长，显得这个类十分的庞大。
• 随着时间的推移，他会有更多的方法来处理其它结点，因为我们还有可能要查询其它系统的数据加在后面
• 没有经过设计，没有抽象，没有职责分配，不符合面向接口编程的理念
• 一但A版本停止运行，更改方式只有注释代码，后来的维护人可能还不敢删除，只会留下一堆无用的注释。

分析设计

基于上面的分析，做出如下分析，面向对象的接口重点是分析出接口，也就是他们通的东西，其实这个接口就是要做下面几件事情。

接口设计

• 查询A版本的待办的数据，并重新刷新PAGEVO，用于前台显示页列表
• 查询A版本的数据列表，并转换成B版本的格式，并填充到返回值中，（仅当页数大于A版本的页数的时候

B版本查询方法的改造

根据不同的待办编码分发（通过spring的工厂模式）到不同的接口实现中，将职责分开，达到设计中的平均分配智能的效果。

设计图

带来的好处

• 代码的整体结构不变，不改变原来的代码结构。
• 新的查询节点过来，只要实现接口就好。
• 代码的侵入性下降，可维护性增强
• 代码的智能被平均分配

扩展思考

接口其实就是相同的地方抽象并定义出来，实现就是针对抽象的实现，这就是中国人所说的求同存异。