重构这个大类的基本思路还是来源于业务逻辑的划分，可以看到work中主要完成3件事：下载文件、合并文件和处理单词，这里可以采用模板模式：
具体的实现在HandleTempleImpl里面：
这样对于真正的处理就能够比较充分地测试，比如mergeFile()现在完全不依赖与downLoadFile()的调用而可以直接测试了。
四、原则与总结
以上实例只是一些普遍性较强的例子，实际上细节点非常多，从上也可明显看出如果代码结构不合理可测性确实是非常低的。
这里有一些代码书写或者重构的原则，对于提高可测性有较大的帮助，较全的重构方法可以参考《重构》这本经典书籍：
1）形成模板方法（如3.3模板模式的应用）
2）引入断言（比如每个方法中判断传入参数的合法性，这样在测试时可以减少异常参数测试的工作量）
3）用多态替代条件语句（如3.2策略模式的应用）
4）用异常代替错误码（测试时只需要调用后判断预期异常）
5）将查询方法与修改方法分离（测试时由于查询和修改职责单一后会降低构造数据的成本）
6）以明确函数取代参数（测试时由于函数明确、职责单一也会降低构造数据成本）
另外，在测试时也有一些tips：
1）用TestNG或者Junit的参数化来减少代码量，并尽量将测试数据单独一个类出来；
2）用ObjectFactory的方式来获取默认数据，这样对于构造拥有多个属性的类的实例时将大大减少工作量，因为只需要在默认对象的基础上做些修改；
3）使用Mokito的注解方式来mock对象。
