当重构遇上IoC
当重构遇上IoC
缘起OO和重构
引言
记得在大学的时候，OO思想像一首流行歌曲一样只要是学计算机的同学都会说的朗朗上口。你或许会问什么是OO，当时的我们（大部分）会说的像唱歌一样，封装，继承，多态。你或许会再问，怎么实现，我们会说：封装就是把属性Get，Set 隐藏实现。继承就是有个父类子类就去继承它来达到重用，多态就是指类对象动态指向父类的现象叫多态。那时候知道的OO都是口头上的仅此而已.
记得我一个睡上铺的哥们，买了几本大师级的书叫人月神话，Java编程思想，设计模式之类的，当时就鄙视他想问句你真看的懂吗？因为没有编写的代码量到一定数量，看了也是白看，因为自己也是做这行的没办法也了一两本也常常有系里的同学用鄙疑的眼神从我身边走过。那时好像自己没本那样的书都不Fashion …….
很多人一翻开 重构，设计模式 等就像进入了一个“空中花园”，那么多的技巧让你感叹，会花很多时间去理解。可是一合上书，马上又进入了另一片天地，“空中花园”离你是那么遥远，高高在上。 随着你编写的代码量达到一定高度才渐渐理解它们的应用场景和所解决的问题。
什么是重构？
重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
重构的好处
显而易见的大概有这么几点:容易阅读，找到潜在Bug,提高软件效率，降低维护成本。
什么时候重构?
三次法则
第一次做某件事时只管去做;第二次做类似的事会产生反感，但无法如何还是做了;第三次再做类似的事，你就应该重构。
- 添加功能时一并重构
- 修补错误时一并重构
- 复审代码时一并重构
但软件无法正常运行或到软件交付期时不应该重构
下面是自己写代码重构遇到的几个阶段
代码级重构
刚开始的时候常常Ctrl+C和Ctrl+V 10个页面就10个Ctrl+V，开始的时候觉得Ctrl+V是最节省时间的，而且方便。读书的时候做个小项目练下手，但是很多地方用Ctrl+C和Ctrl+V，记得最多的一次是，做个权限验证，用户登录后获取该用户的权限。当该用户访问该页面时就验证该用户是否有该页面访问权限。我把用户信息缓存在本地，在每个页面构造函数里加验证判断，如果验证失败就跳转到提示页，我当时记得有30个页面左右。复制 30左右次眼睛累的不行，因为怕复制漏了或者复制错了。Ctrl+V完后测试，我去，验证规则写的有漏洞，之后每个页面一个一个改，30个页面啊， 改完测试，没什么问题，但后来功能不能满足需求，就改User表，验证方式也变了，没办法又要每个页面改代码。。。。极其痛苦，血的教训！
代码级的重构还有很多如 重命名，封装字段，改善可读性,添加注释等重构。
方法级重构
知道痛了才会改变，渐渐的学会把公有的部分提取到一个方法里。方法尽量简单，功能专一。以不变应万变。方法重载和省缺参数也在不同是情况下使用
我们会在工作中慢慢积累很多通用方法如分页，SqlHelper,图片处理，随机数等，随着开发经验的增多，公用方法就会越来越多并成为自己宝贵的资源。
实体，结构级重构——继承和多态
常常在刚开始的时候我们会使用继承，随着需求的变化我们的父类可能会添加新属性或方法，慢慢的我们会发现继承可能造成无限膨胀，而且子类是受害者会继承些完全不需要的东西影响性能，慢慢实体的维护修改变的异常艰难牵扯也会很多。
后来发现继承应该少用，除非在很强的父子继承关系时才用，用耦合的灵活性远远高于继承.
个人认为多态是面向对象的核心，我之前常常在实体结构中不知道何时用多态，再后来慢慢的困惑我的是,在使用多态的时候是用抽象类还是接口。
后来我们听说说面向抽象编程（面向接口编程），高内聚低耦合的思想 才找到多态的用处。慢慢的我们会将对象和行为分离抽象出接口实现来避免大基类的设计。把抽象或实现完全分离来应对需求的变化。
在这我们常常也会用到一些设计模式来应对变化和扩展。
模块级的重构
之前我们可能会为页面和业务逻辑，业务逻辑和数据实例化而伤透脑筋。后才我们知道为了更好组织各层开发，隔开耦合，我们也会采用MVC、MVP、MVVM模式或分层开发；
在项目中为了解除各模块和组件的耦合，我们也会利用IOC的思想解耦我们会引入IOC框架；
在此如果项目数据处理量不是特别大，为了使项目的开发速度更快且更方便，我们也会引入ORM思想来加快项目的开发速度和可维护性；
在用户不断增加系统压力逐渐增大用户漫长的等待时，我们可能会考虑自己写缓存机制或引入缓存架构
如果我们应用程序和服务会交错，我们可能会考虑用SOA架构，WCF，web service等
常常遇到的困惑
在系统越做越大的时候，每次开发部门接到新需求或需求变更大家心里好像都有一些凉意，怕自己一个微小的变化所需的努力，将自己或整个项目引入错误的恐惧。或许你在心里想高呼一声：“上帝,让我们重来一次吧，我们一定做到接近完美。。。”。呵呵，我以前常常在做像这个的白日梦。重构是持续性的没有人能够把系统一次性重构非常完美的，就算当时完美随着时间，需求的推移和变更，我们还需要重构。这种现象主要有几个原因导致的：
- 没有勇气去重构，怕出错给自己带来没必要的麻烦。
- 自己昏天黑地，看其他同事逍遥快活，心理不平衡。导致自己跃跃欲试的重构计划成为虚构。
- 工程量太大，望而怯步。如果要大量改接口或结构的话，还是劝你重写吧。
重构是程序员必然经历的过程，发展到现在书籍和工具已经有很多，重构—— 改善既有代码的设计和圣殿骑士的 31天重构 推荐下。重构工具自己用过的除了Vs自带的，就是 ReShaper 非常棒的一个工具可以帮你分析，发现需要重构的地方。下篇说到IOC. 未完待续……
