1、Rename Method（函数改名）
我极力提倡的一种编程风格就是：将复杂的处理过程分解成小函数。但是，如果做得不好，这会使你费尽周折却弄不清楚这些小函数各自的用途。要避免这种麻烦，关键就在于给函数起一个好名称。函数的名称应该准确表达它的用途。给函数命名有一个好办法：首先考虑应该给这个函数写上一句怎样的注释，然后想办法将注释变成函数名称。
2、Add Parameter（添加参数）
Add Parameter是一个很常用的重构手法，我几乎可以肯定你已经用过它了。使用这项重构的动机很简单：你必须修改一个函数，而修改后的函数需要一些过去没有的信息。因此你需要给函数添加一个参数。
3、Remove Parameter（移除参数）
程序员可能经常添加参数，却往往不愿意去掉它们。他们打的如意算盘是：无论如何，多余的参数不会引起任何问题，而且以后还可能用上它。
4、Separate Query form Modifier（将查询参数和修改参数分离）
如果某个函数只是向你提供一个值，没有任何看得到的副作用，那么这是个很有价值的东西。你可以任意调用这个函数，也可以把调用动作搬到函数的其他地方。简而言之，需要操心的事情少多了。
5、Parameterize Method（令函数携带参数）
你可能会发现这样的两个函数：它们做着类似的工作，但因少数几个值致使行为略有不同。这种情况下，你可以将这些各自分离的函数统一起来，并通过参数来处理那些变化情况，用以简化问题。这样的修改可以去除重复的代码，并提高灵活性，因为你可以用这个参数处理更多的变化情况。
6、Replace Parameter with Explicit Methods（以明确函数取代参数）
Replace Parameter with Explicit Methods恰恰相反于Parameterize Method。如果某个参数有多种可能的值，而函数内又以条件表达式检查这些参数值，并根据不同参数值做出不同的行为，那么就应该使用本项重构。调用者原本必须赋予参数适当的值，以决定该函数做出何种响应。现在，既然你提供了不同的函数给调用者使用，就可以避免出现条件表达式。此外你还可以获得编译期检查的好处，而且接口也更清楚。如果以参数值决定函数行为，那么函数用户不但需要观察该函数，而且还要判断参数值是否合法，而“合法的参数值”往往很少在文档中被清楚地提出。
7、Preserve Whole Object（保持对象完整）
有时候，你会将来自同一对象的若干项数据作为参数，传递给某个函数。这样做的问题在于：万一将来被调用函数需要新的数据项，你就必须查找并修改对此函数的所有调用。如果你把这些数据所属的整个对象传给函数，可以避免这种尴尬的处境，因为被调用者函数可以向那个参数对象请求任何它想要的信息。
8、Replace Parameter with Methods（以函数取代参数）
如果函数可以通过其他途径获得参数值，那么它就不应该通过参数取得该值。过长的参数列会增加程序阅读者的理解难度，因此我们应该尽可能缩短参数列的长度。
9、Introduce Parameter Object（引入参数对象）
你常会看到特定的一组参数总是一起被传递。可能有好几个函数都使用这一组参数，这些函数可能隶属同一个类，也可能隶属不同的类。这样一组参数就是所谓的Data Clumps（数据泥团），我们可以运用一个对象包装所有这些数据，再以该对象取代它们。哪怕只是为了把这些数据组织在一起，这样做也是值得的。本项重构的价值在于缩短参数列，而你知道，过长的参数列总是难以理解的。此外，新对象所定义的访问函数还可以使代码更具一致性，这又进一步降低了理解和修改代码的难度。
10、Remove Setting Method（移除设置函数）
如果你为某个字段提供了设值函数，这就暗示这个字段值可以被改变。如果你不希望在对象创建之后此字段还有机会被改变，那就不要为它提供设值函数（同时将该字段设为final）。这样你的意图会更加清晰，并且可以排除其值被修改的可能性：这种可能性往往是非常大的。
11、Hide Method（隐藏函数）
重构往往促使你修改函数的可见度。提高函数可见度的情况很容易想象：另一个类需要用到某个函数，因此你必须提高该函数的可见度。但是要指出一个函数的可见度是否过高，就稍微困难一些。理想状况下，你可以使用工具检查所有函数，指出可被隐藏起来的函数。即使没有这样的工具，你也可以时常进行这样的检查。
12、Replace Constructor with Factory Method（以工厂函数取代构造函数）
使用Replace Constructor with Factory Method的最显而易见的动机，就是在派生子类的过程中以工厂函数取代类型码。你可能常常需要根据类型码创建相应的对象，现在，创建名单中还得加上子类，那些子类也是根据类型码来创建。然而由于构造函数只能返回单一类型的对象，因此你需要将构造函数替换为工厂函数。
13、Encapsulate Downcast（封装向下转型）
在强类型OO语言中，向下转型是最烦人的事情之一。之所以很烦人，是因为从感觉上来说它完全没有必要：你竟然越俎代庖地告诉编译器某些应该由编译器自己计算出来的东西。但是，由于计算对象类型往往比较麻烦，你还是常常需要亲自告诉编译器对象的确切类型。向下转型在Java特别盛行，因为Java没有模板机制，因此如果你想从集合之中取出一个对象，就必须进行向下转型。
14、Replace Error Code with Exception（以异常取代错误码）
和生活一样，计算机偶尔也会出错。一旦事情出错，你就需要有些对策。最简单的情况下，你可以停止程序运行，返回一个错误码。这就好像因为错过一班飞机而自杀一样（如果真那么做，哪怕我是只猫，我的九条命也早赔光了）。尽管我的油腔滑调企图带来一点幽默，但这种“软件自杀”选择的确是有好处的。如果程序崩溃代价很小，用户又足够宽容，那么就放心终止程序的运行好了。但如果你的程序比较重要，就需要以更认真的方式来处理。
15、Replace Exception with Test（以测试取代异常）
异常的出现是程序语言的一大进步。运用Replace Error Code with Exception，异常便可协助我们避免很多复杂的错误处理逻辑。但是，就像许多好东西一样，异常也会被滥用，从而变得不再让人愉快。“异常”只应该被用于异常的、罕见的行为，也就是那些产生意料之外的错误行为，而不应该成为条件检查的替代品。如果你可以合理期望调用者在调用函数之前先检查某个条件，那么就应该提供一个测试，而调用者应该是用它。