java代码重构

最近工作中会用到java代码重构。于是在查找这方面的资料。涉及到几点记录下来，方便日后查阅。
重构重点
1.Duplicated Code(重复代码) 
同一个类的两个函数含有相同的表达式，需要将重复的这段代码提出来，让这两个函数都调用这段代码,两个互为兄弟的子类内含相同表达式，需要将代码提炼出来放入父类中; 
如果两个毫不相关的类出现重复代码需要将其提炼到一个独立类中，然后在另一个类内使用这个新类，抑或这个函数可能属于第三个类，而另两个类应该引用这第三个类;

2.Long Method(过长函数) 
拥有短函数的对象会活得比较好、比较长。解释能力、共享能力、选择能力——都是由小型函数支持的。每当感觉需要以注释来说明点什么的时候，就把需要说明的东西写进一个独立函数中，并以其用途命名，方便其他方法调用。

3.Large Class(过大的类) 
一个类如果拥有太多代码，就需要将其拆分，可以先确定客户端如何使用它们，然后为每一种使用方式提炼出一个接口; 
产生条件:这个类实例变量太多，必然会有重复代码 ;类内如果有太多代码，整个类看起来混乱并最终走向死亡。

4.Long Parameter List(过长参数列) 
太长的参数列难以理解，太多参数会造成前后不一致、不易使用，而且一旦需要更多数据，就不得不修改它，可以把函数所需要的东西通过对象传入; 
一旦你需要更多的数据，你就不得不去修改它。相反如果你通过传入对象，首先你的参数列表就很短，其次如果你想增加别的变量，会有可能只需要在函数中对这个参数对象新增属性就行了。

5.Divergent Change(发散式变化) 
如果某个类经常因为不同的原因在不同的方向上发生变化，就会出现发散式变化，如增加一个功能需要修改多处，这时应该把针对某一外界变化的所有相应修改都放在一个类中;时刻要记住这么一句话：针对某一外界变化的所有相应修改，都应该产生在单一类中，而这个新类中的所有内容都应该反应此变化。

6.Shotgun Surgery(霰弹式修改) 
如果每遇到某种变化，就必须在许多不同的类内做出许多小修改，这就是霰弹式修改，应该把需要修改的代码放进同一个类，如果没有合适的类就创建一个。

7.Feature Envy(依恋情结) 
如果一个函数为了计算某个值，需要用到几个类的数据，就把函数移到最多被此函数使用的数据的类中;面向对象技术就是将数据和行为包装在一起。一个经典的场景就是函数对某个类的兴趣高过对自己所处类的兴趣，往往焦点就是数据。很多时候我们可以看到这种场景，类A中的函数为了进行计算获取了类B中几乎一半的数据，面对这种情况，其实很简单，就是将这个函数直接移到B中去，然后让类A的调用点就调用类B的这个函数。如果一个函数中，只有一部分受这种“依恋之苦”，你应该用提取方法把这一部分提炼出来，然后把这个提炼的函数移动到他所依恋的类中去。如果出现一个函数需要用到几个类的时候，我们会很难判断究竟应该把它放哪。这个时候有个小技巧你只要记住，这个函数获取哪个类的数据最多，就把这个函数移动到哪个类中去。当然面对这种多重以来，你也可以将这个函数分解成一系列小函数然后移动到他们对应的需要的类中去也可以轻松完成。

8.Data Clumps(数据泥团) 
总是绑在一起出现的数据应该拥有属于它们自己的对象，评判方法是：删掉众多数据中的一项，如果其他数据没有意义了，那就应该为它们产生一个新对象;可以使用复用,让他们拥有属于他们自己的行为,简化参数列表

9.Primitive Obsession(基本类型偏执) 
大多数编程环境都有两种数据：结构类型允许你将数据组织成有意义的形式；基本类型则是构成结构类型的积木块。结构总是会带来一定的额外开销，它们可能代表着数据库中的表，如果只为做一两件事而创建结构类型也可能显得太麻烦;

10.Switch Statements(switch) 
面向对象中压根就不需要存在swtich,多态给了比swtich更优雅的解法。swtich语句本身就代表了重复，你在需要做类型判断的时候你就需要写这一长串的swtich不说，当你要增加新的类型你就需要寻找这些所有的swtich，维护工作非常困难。大多数时候，当你一看到swtich语句，你就应该考虑用多态来优雅的解决。问题是这个多态应该出现在哪 ？swtich语句常常跟类型码有关，你所要做的就是寻找与这些类型码有关的函数或类。应该抽取方法把这个swtich语句提炼到一个独立函数中去，然后搬移到需要多态性的那个类里。接下来你需要考虑是否使用替换类型代码wtih子类或者用状态/策略替换类型代码。一旦这样的继承结构完成之后，你就可以运用多态性来优雅的进行解决了。

11. Parallel Inheritance Hierarchies(平行继承体系) 
当你为某一个类增加子类的同时你必须为别的类同时增加子类。有个简单办法可以判断，当你发现某个类的继承体系前缀和另外一个继承体系前者完全相同，就会出现问题。
解决这个办法的一般策略就是让一个继承体系的实例去引用另外一个继承体系的实例。然后不断运用移动方法和移动字段到被引用端，你就可以将引用端的继承体系完全打破，做到被引用端单一的继承体系。

12.Lazy Class(冗赘类) 
虽然面向对象世界带给我们对象的魅力，但并不是类越多就越好。虽然加入间接层可以带来各种方便，但所有的类都是需要人能够去理解和维护的。对于那些实际作用不大的类，或者因为某些重构原因让它变得没有价值的时候，或开发者事前规划了某些类来应对变化，但实际上并没有发生这些变化。不论上述哪一种原因，就让这个类消失好了，这样减少你的工作量的同时也在减少别人的工作量，因为很有可能将来维护代码的人还是你自己。对于几乎没有用的组件，你可以运用内联类来对付它们。