重构这个大类的基本思路还是来源于业务逻辑的划分，可以看到work中主要完成3件事：下载文件、合并文件和处理单词，这里可以采用模板模式：

　　具体的实现在HandleTempleImpl里面：

　　这样对于真正的处理能够比较充分地测试，比如mergeFile()现在完全不依赖与downLoadFile()的调用而可以直接测试了。

　　四、原则与总结

　　以上实例只是一些普遍性较强的例子，实际上细节点非常多，从上也可明显看出如果代码结构不合理可测性确实是非常低的。

　　这里有一些代码书写或者重构的原则，对于提高可测性有较大的帮助，较全的重构方法可以参考《重构》这本经典书籍：

　　1）形成模板方法（如3.3模板模式的应用）

　　2）引入断言（比如每个方法中判断传入参数的合法性，这样在测试时可以减少异常参数测试的工作量）

　　3）用多态替代条件语句（如3.2策略模式的应用）

　　4）用异常代替错误码（测试时只需要调用后判断预期异常）

　　5）将查询方法与修改方法分离（测试时由于查询和修改职责单一后会降低构造数据的成本）

　　6）以明确函数取代参数（测试时由于函数明确、职责单一也会降低构造数据成本）

　　另外，在测试时也有一些tips：

　　1）用TestNG或者Junit的参数化来减少代码量，并尽量将测试数据单独一个类出来；

　　2）用ObjectFactory的方式来获取默认数据，这样对于构造拥有多个属性的类的实例时将大大减少工作量，因为只需要在默认对象的基础上做些修改；

　　3）使用Mokito的注解方式来mock对象。