文章内容
本文主要借鉴了《重构，改善既有代码的设计》与《设计模式>》这两本书。其主要解释重构的原理（principles）和最佳实践方式（best practices），并指出何时何地你应该开始挖掘你的代码以求改善。 《重构，改善既有代码的设计》 核心是一份完整的重构名录（catalog of refactoring），其中每一项都介绍一种经过实证的代码变换手法（code transformation）的动机和技术。某些项目如Extract Method和Move Field看起来可能很浅显，但不要掉以轻心，因为理解这类技术正是有条不紊地进行重构的关键。该书所提的这些重构准则将帮助你一次一小步地修改你的代码，这就减少了过程中的风险。很快你就会把这些重构准则和其名称加入自己的开发词典中，并且朗朗上口。
重构重点及准则
1、Duplicated Code(重复代码)
同一个类的两个函数含有相同的表达式，需要将重复的这段代码提出来，让这两个函数都调用这段代码,两个互为兄弟的子类内含相同表达式，需要将代码提炼出来放入父类中。
如果两个毫不相关的类出现Duplicated Code，需要将重复代码提炼到一个独立类中，然后在另一个类内使用这个新类，抑或这个函数可能属于第三个类，而另两个类应该引用这第三个类。
2、Long Method(过长函数)
拥有短函数的对象会活得比较好、比较长。解释能力、共享能力、选择能力——都是由小型函数支持的。每当感觉需要以注释来说明点什么的时候，就把需要说明的东西写进一个独立函数中，并以其用途命名。
3、Large Class(过大的类)
一个类如果拥有太多代码，就需要将其拆分，可以先确定客户端如何使用它们，然后为每一种使用方式提炼出一个接口。
产生条件：这个类实例变量太多，必然会有Duplicated Code(重复代码) ;类内如果有太多代码，也会产生Duplicated Code，让整个类看起来混乱并最终走向死亡。
4、Long Parameter List(过长参数列)
太长的参数列难以理解，太多参数会造成前后不一致、不易使用，而且一旦需要更多数据，就不得不修改它，可以把函数所需要的东西通过对象传入。
一旦你需要更多的数据，你就不得不去修改它。相反如果你通过传入对象，首先你的参数列表就很短，其次如果你想增加别的变量，会有可能只需要在函数中对这个参数对象多加一次请求就行了。
如果向已有的对象发送一条请求可以取代一个参数，那么你应该使用Replace Parameter with Method。注意是已有的参数，不是不存在的参数。这个需要理解一下，已有的参数就是函数宿主类中的某一个对象字段，也可能是函数本身存在另一个对象参数，让这个对象来替换它。如果某些数据缺乏合理的对象归属。可以使用Introduce Parameter Object来为它们制造一个“参数对象”。
5、Divergent Change(发散式变化)
如果某个类经常因为不同的原因在不同的方向上发生变化，就会出现Divergent Change，如增加一个功能需要修改多处，这时应该把针对某一外界变化的所有相应修改都放在一个类中;时刻要记住这么一句话：针对某一外界变化的所有相应修改，都应该产生在单一类中，而这个新类中的所有内容都应该反应此变化。
6、Shotgun Surgery(霰弹式修改)
如果每遇到某种变化，就必须在许多不同的类内做出许多小修改，这就是Shotgun Surgery，应该把需要修改的代码放进同一个类，如果没有合适的类就创建一个。
7、Feature Envy(依恋情结)
如果一个函数为了计算某个值，需要用到几个类的数据，就把函数移到最多被此函数使用的数据的类中;面向对象技术就是将数据和行为包装在一起。一个经典的坏味道的场景就是函数都某个类的兴趣高过对自己所处类的兴趣，往往焦点就是数据。很多时候我们可以看到这种场景，类A的中的函数为了进行计算获取了类B中几乎一半的数据，面对这种情况，其实很简单，就是使用Move Method将这个函数直接移到B中去，然后让类A的调用点就调用类B的这个函数。如果一个函数中，只有一部分受这种“依恋之苦”，你应该用Extract Method把这一部分提炼出来，然后通过Move Method把这个提炼的函数移动到他所依恋的类中去。如果出现一个函数需要用到几个类的时候，我们会很难判断究竟应该把它放哪。这个时候有个小技巧你只要记住，这个函数获取哪个类的数据最多，就把这个函数移动到哪个类中去。当然面对这种多重以来，你也可以用Extract Method将这个函数分解成一系列小函数然后移动到他们对应的需要的类中去也可以轻松完成。
8、Data Clumps(数据泥团)
总是绑在一起出现的数据应该拥有属于它们自己的对象，评判方法是：删掉众多数据中的一项，如果其他数据没有意义了，那就应该为它们产生一个新对象;可以使用复用,让他们拥有属于他们自己的行为,简化参数列表。
9、Primitive Obsession(基本类型偏执)
大多数编程环境都有两种数据：结构类型允许你将数据组织成有意义的形式；基本类型则是构成结构类型的积木块。结构总是会带来一定的额外开销，它们可能代表着数据库中的表，如果只为做一两件事而创建结构类型也可能显得太麻烦。
10、Switch Statements(switch)
文中作者用了“惊悚”来形容swtich语句，的确，面向对象中压根就不需要存在swtich,多态给了比swtich更优雅的解法。swtich语句本身就代表了重复，你在需要做类型判断的时候你就需要写这一长串的swtich不说，当你要增加新的类型你就需要寻找这些所有的swtich，维护工作非常困难。大多数时候，当你一看到swtich语句，你就应该考虑用多态来优雅的解决。问题是这个多态应该出现在哪 ？swtich语句常常跟类型码有关，你所要做的就是寻找与这些类型码有关的函数或类。应该先用Extract Method把这个swtich语句提炼到一个独立函数中去，然后运用Move Method把它搬移到需要多态性的那个类里。接下来你需要考虑是否使用Replace Type Code wtih Subclass或者Replace Type Code with State/Strategy。一旦这样的继承结构完成之后，你就可以运用Replace Condiional with Polymorphism来优雅的进行解决了。
11、Parallel Inheritance Hierarchies(平行继承体系)
Parallel Inheritance Hierarchies其实是Shotgun Surgery的特殊情况。意思就是当你为某一个类增加子类的同时你必须为别的类同时增加子类。有个简单办法可以判断，当你发现某个类的继承体系前缀和另外一个继承体系前者完全相同，你便闻到了这股坏味道。
解决这个办法的一般策略就是让一个继承体系的实例去引用另外一个继承体系的实例。然后不断运用Move Method和Move Field到被引用端，你就可以将引用端的继承体系完全打破，做到被引用端单一的继承体系。
12、Lazy Class(冗赘类)
虽然面向对象世界带给我们对象的魅力，但并不是类越多就越好。虽然加入间接层可以带来各种方便，但所有的类都是需要人能够去理解和维护的。对于那些实际作用不大的类，或者因为某些重构原因让它变得没有价值的时候，或开发者事前规划了某些类来应对变化，但实际上并没有发生这些变化。不论上述哪一种原因，就让这个类消失好了，这样减少你的工作量的同时也在减少别人的工作量，因为很有可能将来维护代码的人还是你自己。如果子类没有做足够的工作，可以运用Collapse Hierarchy来打破继承体系，对于几乎没有用的组件，你可以运用Inline Class来对付它们。
对象技术的新手通常不愿意在小任务上运用小对象，但是对象的一个极大的价值在于：它们模糊(甚至打破)了横亘于基本数据和体积较大的类之间的界限。