记录重构的心得

记录重构的心得

第一次重构

要实现的效果：

将一些自定义的控件封装到一个模块组件中；
操作:
这些自定义的控件UI上做了大改动，并且自定义得更加通用化/可配置化。（建造者模式）
（基本，新的每一个自定义控件可以顶替原来的好几种控件。）
因此，暴露出来的方法是更加灵活的，同时也遗留下了问题：

问题：

不能很好地实现控件的替换工作。因为原来的项目其实是特别庞大的项目。很多自定义控件
都是需要直接换掉的。

解决：

采取了几种方案：一是直接手动换新的；但是改到最后，还有一些类型的控件是有一两百处调用的地方。改起来真的很麻烦，还可能会出现问题。

那我想起了看过的一本《重构》的书，里面有这么一句话：“重构技术就是以微小的步伐修改程序。”。所以，我换了另一种方式来做这个替换工作，就是修改原有自定义控件的接口，将原自定义控件的接口实现都指向我新封装的控件。最后成功了，也大大节约了时间。

第二次重构经历

将代码组件化
问题一：组件对app模块的调用问题。
解决方案：通过一个中间组件——路由成功解决。
问题二：两个非app的组件间的相互调用。
解决方案：这个是比较需要花心思的问题。
最终具体解决：
1.分析问题，然后确定了最终哪个来调用另一个。
2.另一个会调用到的地方。将这个放到app模块上去。
（原本还想了好几种方案：
1.再建一个组件，用来存放着会相互调用这两个组件的文件；
2.通过路由的方式，来解决。
3.将这两个组件合并为一个组件，但是这两个组件我已经分得很明确了，而已都迁移得差不多了。重新搞，太费功夫了。而前两个方案，也会间接将这两个组件绑定在一起了。我觉得还是有违我重构的初衷的。
所以都一一否决了。用了最前面提到的这个方案了,最终方案：仅可以允许其中一个组件依赖另一个组件。然后，相互依赖的，又从功能上区分是隶属其中一个组件的类，则放到了app模块上去。）

dialogFragment
why：所有的dialog都改掉，用成dialogFragment，这个是目前官方比较推荐的用来管理对话框的，他可以更好的处理生命周期，特别是对于需要旋转屏幕的时候，不会因此使dialog自动消失的问题。
how：然后封装成一个比较通用的dialogFragment。
why：另外，使用这个DialogFragment的另一个好处是将对话框的代码脱离出来，减轻Activity的压力，并且通过一个统一的通用的dialogFragment，也可以减少写重复代码，代码风格上也好许多。