首页 > 代码库 > 重构,改善既有代码的设计--总结篇
重构,改善既有代码的设计--总结篇
一、书中经典句子
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;}//好处:使得获取的数据更加有效