重构，改善既有代码的设计--总结篇
重构，改善既有代码的设计--第一章感悟
一、书中经典句子
1.重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验能力。
2.面对长长的函数，需要分解，代码块越小越好管理。
二、自己总结的句子
1.修改长长的函数，找到变的参数和不变的参数，变的参数保留，不变的参数传入新函数。
2.重构的时候使用快捷键重构之后，需要检查方法里面的参数，参数如果是不变的值如a=1;，直接在方法里面去定义就行了，这样就省去了传值的过程，效率更高。
3.在重构函数之后，若函数的参数不属于当前类，并且函数中没使用当前类，需要把方法移动到参数所属的类去；如：A类里面的方法
DoSomething(B b){b.getLabel(){}//do many things}；
需要移动到B类中去,
4.重构之后需要检查下被重构的函数被多少个地方使用，保证无错
5.对于接受一个方法返回值的参数如var a=B.getA();在这里a是完全没有必要的，可以直接把它给删除，在使用到a的地方替换为B.getA()
6.为了使得方法看起来更加简洁，可以把方法中的变量和使用到变量的逻辑给抽取出来，形成一个方法，删除变量之后再使用到变量的地方用方法替代。
7.在switch语句，最好不要在另一个对象的基础上运用switch语句。如果不得不使用，也应该在对象自己的数据上使用，而不是别人的数据上使用。比如：A类中的方法MethodA()中的switch里面使用的都是B类对象引用的数据如：case B.NUMBER;则需要把该方法转移到B类中去，以减少没必要的引用。
重构，改善既有代码的设计--第二章感悟
一、摘取章句
1.改进设计的重要方向是消除重复代码。
2.力求代码容易理解
3.早起重构被描述为“擦掉窗户上的污垢，使你看得更远。”
二、何时重构
1.在给软件添加功能的时候重构
2.修补错误时候重构：在重构中来找出系统的bug
3.复审代码时候重构
4.个人觉得在功能完成之后顺便重构会更好，因为在那个时候对代码还是很熟悉，还有可以在重构的时候去发现开发过程中遗留下来的bug
重构，改善既有代码的设计--第四章感悟
1.类应该包含它们的测试代码。每个类都应该有一个测试函数
重构，改善既有代码的设计--第六章感悟
以下摘自书中内容：
一.对付过长函数的方法
1.Extra Mehtod:就是把一段代码才从原先函数中提取出来，放入一个单独函数中。最大困难就是处理局部变量。（创造新函数要根据这个函数的意图来对它命名，以它“做什么”来命名，而不是以它“怎么做”命名。）
二、内联函数
当函数本体和名称同样清晰易懂需要合并两个函数：如：
int _moreThaFiveLateDeliveriens=0; public int getRating() { return (moreThaFiveLateDeliveriens())?2:1; } boolean moreThaFiveLateDeliveriens() { return _moreThaFiveLateDeliveriens>5; }
变成
int _moreThaFiveLateDeliveriens=0; public int getRating() { return (_moreThaFiveLateDeliveriens>5)?2:1; }
三、内联临时变量
double basePrice=anOrder.basePrice(); return (basePrice>1000); 改为 return (anOrder.basePrice()>1000);
四、找变量做法
1.找出只被赋值一次的临时变量；如果某个变量被赋值超过一次，考虑将它分割为多个变量，
将该变量声明为final。
2.将复杂表达式的结果放在一个临时变量，以此变量的名称来解释表达式用途。
3.对那些被赋值不止一次的临时变量，需要针对每次赋值，创造一个独立、对应的临时变量。将新的临时变量定义为final类型。
比如：int a=2*3(10+11);
a=1*121*1111;
换成：int a=2*3(10+11);
int b=1*121*1111;
重构，改善既有代码的设计--第七章感悟
1.提炼类
某个类做了应该由两个类做的事，需要建立一个新的类，将相关的字段和函数从旧类搬到新类。
先搬较底层函数（就是给别人调用多过于调用别人的），再搬高层函数。
重构，改善既有代码的设计--第八章感悟
1.如果你看到一个数组的行为方式很像一个数据结构，就可以把数组变成对象
private int aa,变成: int aa;
public int GetAA() {return aa;}//好处：使得获取的数据更加有效
