重构总结

最近公司推崇质量（ms这个是一直要的），而本人也不希望自己的代码在众多的需求里面沉沦。而且在不提重构这档子事情的时候，我已经发现了程序中很多很多地方有坏味道。有些地方简直是对现代软件工程的辱没。没有办法，从头开始，了解重构和模式的相关的知识。
由于在J2ME的平台上做开发，很多模式觉得用起来很别扭，当然不是典型的mvc这种的了。最近使用了策略模式来处理不同的解析策略，但是应用这些策略的时候我感觉进入了一个很尴尬的境地：我的应用没有办法知道当前所用的是哪种策略，我必须在上下文中设置一些值来告诉应用这时候改用第几号或者某种策略了，导致 策略的灵活性还是没有保证，如果能够使用脚本来配置这种访问与被访问的关系就好了。2，代码庞大，应用了很多对象变量，导致函数重构很麻烦，很显然的一个表象就是我在调用某一个方法之后要调用一个clear的操作，这就为使用者增加了使用出错的可能性。3，思路转换方面的问题，总是基于面向过程的思路，偏重算法而非结构，导致算法变更相当麻烦4，名字变更，有些函数名字很大，比如dosomethingafterbargain等，说明这个方法包括了一系列的子方法，需要分割成不同的几个小方法，这样才有组合的可能行，也防止某个小地方改动都需要去修个这个大的方法。5，包结构。包结构的划分主要基于这两个方面：a：名称，包名能代表一个事务，所以最好能用名次确定出来。b：去除引用，这里还要注意函数抛出异常的方式，最好在一个包中只抛出一种异常，并且能够屏蔽底层提供api所产生的异常，这样才可能整体替换这个包，只要包的接口一致即可。有一种思路是将接口放在顶级包结构中，实现分散在各自对应的子包，这样可以使用Ant工具有选择性的选择使用那种实现方式。6.设计模式的使用，模式的好处就是在于可以提供一种大家公认的程序组织方式，可以对需求的最大化的适应，但是，我们到底需要多大的灵活性？因此，在重构中也要注意一些过度设计的问题，不要为遥远的将来预留太多的接口。一个人太关注将来，他眼下的生活就一定不幸福。
以上零零总总的说了一堆，主要还在于实践的把握上，千里之行始于足下。