这真是一个很大、很深的话题，所以我很担心自己不能很好的表达出来或者表达的不到位的地位，欢迎各位吐槽。
很到重构，这一直是我自己的一个痛点，为什么呢？因为在上一个项目里面，我错过了一个很好的锻炼机会，结果我走的时候只是留下来的一大堆有待重构的代码，我想接受我们这个项目的哥们应该是比较痛苦的。在此顺便道一声对不起。我想如果我早一点看到如此精彩的一本书，我应该就不会走了。怪只怪当时的我太年轻，太冲动了。现在想想真的是不应该。
在这本书里面，作者有提到一个很重要的观点就是持续重构和测试驱动编程。我们先来说一说持续重构的意义吧！因为不管任何人，不管你的技术有多牛，你都不可能一次就写出很完美的代码。所以这个时候，我们多多少少会留下一些代码“欠账”，多的时候，可能是因为项目的时间紧张，也有可能是开发的程序能力有限等等各方面的原因。那么什么是代码“欠账”呢？可能你从字面的意思就可以悟出一二了，比如现在因为需要赶项目，匆匆的开发完项目功能，然后又去忙着迭代下一个版本，这之间没有花费一定时间去好好的整理代码的话，那么最后的结果肯定就是：快、慢、更慢的套路了。第一个版本你可能很快就完成了，但是后面的版本迭代的话，你就会很痛苦，最后不得已你可能会想要整个项目推倒重做了。当然，这里面还涉及到一个很重要的概念就是快熟构建第一个基本满足功能的版本问题，其实这种思路是很符合敏捷开发的套路的，在敏捷开发里面就是强调快熟构建，快熟反馈的原则，因为敏捷开发里面相信尽早的反馈有利于最终交付的项目质量。好了，有点跑偏了，让我们回来吧！当初没有想要很好的重构代码的时候，你最终得到的就是一个“大泥球”。那么即使你想要好好的重构你的代码，如果没有很好的方法的话，你也是巧妇难为无米之炊，其中我认为模式就是那缺少的粮米了。
在这本书里面作者很好为我们划分了不同功用的模式。虽然我还没有好好的研究，可是基本作用我大致知道的，以后如果有时间的话，我肯定还是需要回过头来好好重新翻看这本图书的。
首先让我们先来看一看常规的重构方法吧！大部分你可能能够顾名思义，没错它就是那个意思。方法组合重构指的就是：保持方法的短小，意图明确的原则；遇到一个很长的方法，我们需要尽量为其减肥，当一个方法很长的时候，就以为着这里面可能做得不是同一件事情，这个方法里面的细节就不是在一个技术细节里面。我们需要提炼出更多的小方法，在这样的一个个小方法里面，我们的重用机率就大多了。复合重构指的就是：小至一些代码变量的迁移，修改；大至整个类的合并；当你注意到在两个不同的方法里面，其实它们的执行逻辑是一样的，只是它们的操作对象不同。或者两个类的一些方法是一样的都是去进行相同的操作的，这个时候，我们可考虑提取相同的部分，放置到一个更加大的对象里面，然后它们都可以从这个对象继承而来，当然里面也有一个限制需要考虑的就是基类型里面不应该包含太多的方法对象，因为继承之后子类可能是不希望重写那么多的方法。如果你完成这部重构之后，你可能会不知不觉的实现或者趋近Adapter模式了，在这个模式里面强调的思想就是能够适配不同的类型，然后让它们之间共同交互。
当我们实现基本的重构之后，如果我们想要进一步重构怎么办呢？比如你现在发现一些性能问题，可能是因为项目里面构建的实体太多，这个时候，我们自然会想到是不是能够应用singleton模式呢？其实Singleton模式的核心思想就是保证只声明一个实体。一般的情况下，我们都是通过调用构造函数获取一个新的实体的，但是有的时候如果该类的构造函数很多，然后彼此之间的差异又很小的时候，我们就可以自己创建一个Create Method，通过这个方法我们可以很好的隐藏类的一些内部细节。还有在项目里面我们遇到最多的可能就是工厂模式了，还有高级一点的抽象工厂，那么到底工厂模式是怎样实现创建一个实体的呢？其实很简单，我们只要将前面提到的Create Method方法移到工厂类里面就可以，那么什么又是抽象工厂呢？其实只不过是做了进一步的抽象而已，在这个模式里面，需要重新先后一个抽象类，然后每个具体的工厂类，在继承重新里面的创建方法就可以了。
然后让我们来说一说比较高级一点的模式吧！也许你会在项目里面经常遇到很大的条件语句，随着判断逻辑的增加，判断条件也会不断的增加。甚至有的时候我们需要重新在另外一个方法里面满满的再写一遍判断条件，因为这两个判断条件里面需要的执行处理逻辑是不一样的，比如一条里面我们需要更新一下UI，然后第二条里面我们则需要根据不同的条件跳转不同的二级页面，这个时候你可能明知道这里面有一些相同的重复代码，但是没有办法，如果你不知道一定的重构模式，你可能会百思不得其解，这种重复我会有好的方法消除吗？是，其实面对这种情况我们可选择的有Command模式、State模式。它们的区别就是一个是针对命令的，一个针对状态的。State模式的处理思想就是根据不同的状态重构出不同的处理子类，然后调用不同的子类进行处理就可以了。但是我个人认为它们两者之间的处理思想是差不多的。还有一些保护模式：NUllObject模式就是这样的一种模式，很多时候我们的项目需要判断当前的对象的NULL还是!=NULL,这个时候如果只是小部分的这种判断我们还是可以理解的，但是如果是较大部分都这种判断的话，我们就可以采用NULLObjebct模式进行避免了。其思想就是重写一个NUllxxx的类，然后在这个类型里面处理NULL的情况，这样我们就可以不用判断null不null的了。还有一些数据聚集的模式，这里面有两个模式，这要的区别就是针对的对象不一样。我们先说一下什么是数据聚集呢？就是将数据聚集返回，第一种模式相对来说是比较简单的，他真要针对的单个对象，第二种模式就比较难了，它针对的是多个对象之间回去数据返回。
还有一些实现起来比较难的模式：Observor模式、一/多之分模式，当然还有一些其他的模式，我可能一下记不清楚了。如果有兴趣的可以阅读《重构与模式》。