重构总结 2

前一篇说到了程序出现了坏味道，以及坏味道的体现，下面就要着手说明方法论的问题即How  to Refactoring （如何重构的问题）
在要说明这个之前，我强调尽量使用IDE中自带的重构选项下的功能，但是这些功能不会整体上更改你的系统结构，如果结构不合理，重构后的代码也同样是很别扭的。重构的重要原则是little and effective，step by step。
很幸运的，我使用的Java IDE Eclipse中集成了基本的重构选项，包括了重命名，移动，上拉，下推等等
以下详细说明我重构的过程，个人的经历而已。

1. 首先使用名称检查，先在函数名称上检查其是否有一个合适恰当的名字，如果不能用一个名称来描述它说明，这个函数集成了过多的功能。另外在检查函数名称的时候要注意一个度，并不是说程序中不能有大的描述一系列动作的函数，而只是说这一系列的函数应该封装在不同的小函数中。这个大的函数应该描述相对不变的流程性的东西，而每个小函数跟偏向与一个具体动作的策略，这样就把不动部分和变动的部分有机结合起来。
2. 其次，判断是否提供了太多的接口供外部访问。对于一个谨慎的程序员来说，尽可能晚的发布接口，与尽可能少的提供接口是一个规避风险的很好策略。太多的接口，或者为将来的应用提供了太多的接口都是有害的，在这一个重构动作中，你所能做的就是不再增加接口，以减少继任者对你的抱怨。
3. 再次，一个函数是否第一次调用和第二次调用有不同的返回结果么？？如果有的话说明这个函数使用了上下文中的临时存在的变量，维护这些变量使得你的代码存在bad smell。就最近的更改来说，如果对于查询，返回一个枚举就比返回一次查询的一个结果比较好。用查找来代替对临时变量的访问也不失一个手段，但是这样通常会带来系统的性能稍微的下降。
4. 提取中间转换层。这个与mvc结构类似，如果程序代码量较小，c层很可能会集成到m层。在这里也是一样，如果代码量较小，处理中间转换的功能就会向底层隐藏。如果在改动中发现有多个中间转换的过程，将其从隐藏的位置中拿出来也不失一个好的处理方法。另外Adaptor是否强大通常代表着代码是否灵活。通过Adaptor的作用，底层实现和上层的流程分割开

就说这么多 有多少在添加吧