同Introduce Foreign Method一样,很多时候你不能修改编辑原始类,你需要为这些服务类增加一些额外的函数,但你没有这个权限或者入口.如果你只需要一个或者两个外加函数那么你可以放心的使用Introduce Foregin Method,但是如果你发现此时有很多外加函数需要在客户类代码中中添加,你就要小心了,因为你这么做你就会让客户类变得过分复杂,责任就会过分多,你会破坏客户类的单一职责性.这个时候你就可以建立一个新类,让他来包含这些你之前所添加的额外函数,让这个扩展类成为源类的子…

当你无法获得一个类的源代码或者没有权限去修改这个类的时候,你对于这种为你服务的类,你可能会出现需要别的需求的时候,比如一个Date类,你需要能够让他本身直接返回出他的后一天的对象,但他没有,这个时候你就需要暂时使用Introduce Foreign Method来做过渡,并且在适当时候通知作者把这个Foreign Method搬移到他所属于的自己的类中去. 这种情况其实也很多,特别是当你在团队当中,当有别人写了一个类的时候,你会去利用这个类去做你想要做的事情,但如果你发现这个类并没有提供你所要的…

有时候你会遇到一系列复杂的表达式连续运算的时候,这个时候你可能根本招架不住如此长或者是如此复杂的长函数.这个时候你可以通过引用临时变量来储存他们的结果,将这些长函数的结果分成一个个临时变量来让函数清晰化.但在这里,我的想法与作者的想法是一样的,我会更倾向于去用Extract Method去将复杂函数弄清晰,而尽量不去Introduce Explaning Vaiable,因为Extract Method优点很多,除了不增加临时变量增加函数长度之外,他的生命周期也比临时变量来的长,他可以让类中的所…

在编程中,比较忌讳的一件事情就是长函数.因为长函数代表了你这段代码不能很好的复用以及内部可能出现很多别的地方的重复代码,而且这段长函数内部的处理逻辑你也不能很好的看清楚.因此,今天重构第一个手法就是处理长函数--Extract Method,抽取成一个独立的小函数. 我个人来说也很喜欢短小函数,因为他们代表了高强度的复用与灵活性.对于短小函数来说最最关键的就是短小函数的命名,其实你就是给了这些短小函数自我解释的机会,所以你如果给这些短小函数起一个接近其语义的名字,那当你读起长函数来说,就像是阅读…

有时候你会认为某个对象应该是去全局唯一的,这就是引用(Reference)的概念.它代表当你在某个地点对他进行修改之后,那么所有共享他的对象都应该在再次访问他的时候得到相应的修改.而不会像值对象(Value)一样,不可修改.举个例子,你认识小明,我也认识小明,小明忽然把头发都踢了,这个时候你认识的小明和我认识的小明都是同一个人,都是光头,这个小明就是世界的唯一实例,然而,你有100块钱,我有50块钱,我把50块钱花到只剩20,你手里的100块钱并不会因为我的50块钱改变而改变,不会相应的修改,这…

有时候,当你遇到一个大型函数,里面的临时变量和参数多的让你觉得根本无法进行Extract Method.重构中也大力的推荐短小函数的好处,它所带来的解释性,复用性让你收益无穷.但如果你遇到上种情况,你可能会天真的以为我只要适当的进行Replace Temp with Query,就可以把这种现象给化解.但情况往往事与愿违,不能达到你所理想的高度.这个时候你需要用到重构中的杀手锏--Replace Method with Method Object,这个手法出自Kent Beck [Beck].…

当MVC出现的时候,极大的推动了Model与View分离的潮流.然而对于一些已存在的老系统或者没有维护好的系统,你都会看到当前存在大把的巨大类----将Model,View,Controller都写在了一个widget中.一个分层良好的系统,应该将处理用户界面和处理业务逻辑的代码分开.原因如下 如果你此时需要用不同的用户界面来展示数据,比如微软Excel中的饼状图和折线图,他其实内部展示的数据是一样的,但如果你把这两层用户界面逻辑都放在一个widget中去的话,你就会让这个wiget变得复杂无比…

如果你有一个数组,其中的元素各自代表不同东西,比如你有一个 QList<QString> strList; 其中strList[0]代表选手姓名,strList[1]代表选手家庭住址,很显然这个数组表示的含义已经太多,你需要用对象来替换数组,并且对于数组中的每个元素,以一个字段来表示. 数组是一种常见的用以组织数据的数据结构,不过,它们应该只用于“以某种顺序容纳一组相似对象”.对于上面的例子你可以看到一个数组容纳了不同对象,这会给使用数组的客户带来麻烦,因为他们很难记住数组的第一个元素是姓名,…

如果你直接访问一个字段,你就会和这个字段直接的耦合关系变得笨拙.也就是说当这个字段权限更改,或者名称更改之后你的客户端代码都需要做相应的改变,此时你可以为这个字段建立设值和取值函数并且只以这些函数来访问字段. 自古以来,面向对象关于字段访问就存在两个派系,其中一个派系认为,如果在该字段所在的类中,你就可以自由访问他,不需要通过间接的函数来获得.另外一派认为,即使在这个类中你也应该只使用设值和取值函数来间接访问. 当然了,间接访问可以带来的额外好处就是你可以通过子类来覆写函数做到改变获取数据的途径…

明确函数所在类的位置是很重要的.这样可以避免你的类与别的类有太多耦合.也会让你的类的内聚性变得更加牢固,让你的整个系统变得更加整洁.简单来说,如果在你的程序中,某个类的函数在使用的过程中,更多的是在和别的类进行交互,调用后者或者被后者调用,那么你就要注意了,你要去判断这个类是否真正适合他原来所在的类. 简单来说,这套手法就是在该函数最常引用的新类中建立一个有着类似行为的新函数,让旧函数变成一个单纯的委托函数或者完全删掉. Move Method是重构理论的支柱.如果一个类的责任太多,或者一个类和…

当你在一个类中使用字段的时候,发现这个字段必须要和其他数据或者行为一起使用才有意义.你就应该考虑把这个数据项改成对象.在开发初期,我们对于新类中的字段往往会采取简单的基本类型形式来保存,但随着我们开发进度的增加,这些简单的数据项就不再那么简单了.比如一开始你会使用一个字符串来表示一串电话号码,但是随后你会发现,这个电话号码已经变的不再纯粹,它可能还需要“格式化”,“抽取取号”等特殊行为.一开始你可能会不以为意,觉得这个数据项就这么一两个,不会对你造成影响.但重复代码(Duplicate Code…

重构可以把复杂的东西分解成一个个简单的小块.但有时候,你必须壮士断腕删掉整个算法,用简单的算法来取代,如果你发现做一件事情可以有更清晰的方式,那你完全有理由用更清晰的方式来解决问题.如果你开始使用程序库,发现其中库提供的功能特性和你的代码重复,那么你也应该改变你原来的算法.或者当你想要修改原先的算法,让他去做一件和原先略有差异的事情,这时候你也可以把原先的算法替换成一个较易修改的算法,让后续修改来的简单点. 使用这个手法之前,确保自己已经充分了解原先函数,替换巨大而复杂的算法是很复杂的,你可以先…

如果你发现某个类做了过多的简单委托动作,你就可以考虑是否可以让客户直接去调用受托类.在Hide Delegate中,我们介绍了封装受托对象的好处,但好处归好处也存在代价,就是当你每次需要在受托对象中增加新函数的时候你都需要在委托的服务对象中增加相应的函数来委托.随着受托对象特性越来越多,你会发现你所要处理的东西变得越来越复杂,你会感觉这个服务对象完全成为了一个中间人(Middle Man),此时你就应该考虑能否让客户直接去调用受托对象. 你不需要去考虑什么程度的封装才是合理,重构带给你Hide…

在面向对象中,对于类这个概念我们应该有一个清晰的责任认识,就是每个类应该只有一个变化点,每个类的变化应该只受到单一的因素,即每个类应该只有一个明确的责任.当然了,说时容易做时难,很多人可能都会和我一样,一开始建立类的时候信心满满,牢记SRP原则,但随着开发进度的不断进行,很有可能你会给你原本设计好的类增加新字段或者增加新函数,对于少量的增加你可能会因为麻烦,考虑不去单独做一个新类来分解.久而久之,你这个类会变得越来越臃肿,所掌管的责任也会越来越多.这样的类往往还有大量的数据和函数,往往太大而不易…

如果你有一个引用对象,很小且不可改变,而且不易管理,你就需要考虑将他改为一个值对象.在Change Value to Reference我们说过,要在引用对象和值对象之间做选择,有时候并不容易,有了重构,做出选择之后,你还有一条回头路. 如果你发现引用对象开始变得难以使用,你就考虑是否应该把它改为值对象.引用对象必须被某种方式控制,你总是必须向其控制者请求适当的引用对象.如果你让你造成在你系统内存之间变得错综复杂.或者在分布系统和并发系统中,不可变值特别有用(你需要考虑可变对象引用对象他们的同步…

所谓委托关系,就是一个类对于另一个类来说纯粹作为接口转发,即客户通过一个委托类去调用另一个对象.直白的委托关系就是委托类直接返回出目标类给客户调用,这个关系很麻烦,因为委托关系的变动就会影响客户端的代码.隐秘的委托关系很健康,当你完全隐藏之后,你委托关系的变化只会发生在委托类的内部,从而不会去影响客户. 封装是面向对象最关键的特征之一.他意味着系统的每个对象都应该尽可能少的了解系统的其他部分,这样带来的好处就是一旦发生了变化之后,需要了解到这一变化的对象就比较少,这也就意味着你需要改动的代码可以…

如果某个类没有做太多的事情,你可以将这个类的所有特性搬移到另外一个类中,然后删除原类.可以看到,Inline Class正好和Extract Class相反,后者是将一个巨类分解成多个小类从而来分担责任.这里是一个类如果不再承担足够多的责任,不再有单独存在的理由(通常是因为重构动作移除了这个类的责任),我们就会挑选这种类使用最频繁的用户(类),以Inline Class把这个类塞到这个用户类中去. 做法: 寻找源类的所有public接口,然后在你目标类上对这些public接口进行声明,并将其中的…

在类与类之间搬移状态和行为,是重构过程中必不可少的步骤.很有可能在你现在觉得正常的类,等你到了下个礼拜你就会觉得不合适.或者你在下个礼拜创建了一个新的类并且你需要讲现在类的部分字段和行为移动到这个新类中.如果你发现在一个类中的某个字段,更多的被别的类的函数所使用,包括设值set和取值get函数锁取用,那么你就应该考虑搬移这个字段.当然,你也可能会去考虑是否使用Move Method去搬移这些使用这个字段的函数到这个字段的源类中去,这取决于你是否能够接受接口的变化,如果这些函数更加适合待在原地不动…

C++存在按值传递和按引用传递两种传递方式,Java严格按照按值传递这种方式来进行.以按值传递方式的角度来说,如果你 int test(int a) { ) { a = 1; } return a; } 对于传入参数a进行再次赋值就违反了这个规则.因为你对传入参数进行重新赋值会让代码阅读者产生歧义,他们搞不清甚至看不懂你参数到底代表什么含义,甚至会对你这个参数的稳定性表示担忧.当然,如果在C语言中,对于传出参数 int test(int a, int *ok) { ) { a = ; *ok =…

继续开始我们重构手法的系列,今天介绍的是Split Temporary Variable---分解临时变量. 在我们平常写的程序中肯定有某些临时变量被赋予了超过一个的责任.如果他们不是那种收集结果(temp = temp + QString("abc"))或者循环变量(i = i + 1),然而他们却被赋值了多于一次.那么我们肯定说,这个变量被赋予了超过一个的责任,别看这是个小小问题,但这会阻扰我们阅读者的判断,我们会去揣测,这个变量到底是用来干嘛的.从而影响我们看清程序正常的思路.…

Replace Temp with Query,顾名思义,表示你用查询来替换临时变量本身,临时变量对于函数来说是只有当前函数可见的,如果你在同类的别的地方要用到这个变量你就必须重新写表达式来获取这个变量,这样的话你就会在不经意间让你的函数变得复杂起来,所以如果你想要使用Extract Method,那么Replace Temp with Query是必不可少的一个步骤.而我们前面介绍的Inline Temp其实是这个手法的一部分,两者的区别在于Inline Temp已经有了表达式自身,只需要做简…

与Inline Method相同,有时候犹豫需要Extract Method,需要对一些临时变量进行内联,而这个往往是Replace Temp with Query的一部分.简单来说,当你看到这种 double basePrice = anOrder.basePrice(); ); 对于这种情况,basePrice完全是多余的变量,完全可以用函数本身来替代他.这里有个小窍门,你要内联这个变量,你必须要保证函数之后没有对这个变量进行过写操作,换句话说,你可以利用C++的特性----const,将函…

加入间接层确实是可以带来便利,但过多的间接层有时候会让我自己都觉得有点恐怖,有些时候,语句本身已经够清晰的同时就没必要再嵌一个函数来调用了,这样只会适得其反.比如 void test() { if (numGreaterFive()) { qDebug() << "Ok, great!"; } } bool numGreateFive() { ; } 函数名称本身已经表达了这层意思就没必要画蛇添足了,当然我这边只是举了一个很简单的例子,但意思是一致的,就是语义与函数名称本身…

临时变量的问题在于: 它们是暂时的,而且只能在所属函数内使用.由于临时变量只在所属函数内可见,所以,如果很多地方都在用这个临时变量,就会驱使你写出更长的函数.如果把临时变量替换为一个查询,那么其他函数中都可以获得这份信息. 以查询取代临时变量是提炼函数之前必不可少的一个步骤.局部变量会使代码难以被提炼,所以应该尽可能把他们替换为查询式. 这个重构手法较为简单的情况是:临时变量只被赋值一次或者赋值给临时变量的表达式不受其他条件影响. 示例: 初始代码为(2个临时变量): function getP…

看见一个过长的函数或者需要一段注释才能让人理解的代码,可以考虑将这段代码放进一个独立函数中. 创造一个新的函数,根据这个函数的意图来对它命名(以它“做什么”来命名,而不是以它“怎么做”命名). 需要重构的代码如下(代码并不复杂,只是为了说明方法): function print () { var num = 1; console.log('*****************'); console.log('******Hello******'); console.log('***********…

最近公司开发的系统在进行大批量数据查询的时候发现响应速度变得让人无法忍受,so 老大安排我进行代码重构的工作,主要目的就是为提高代码的执行效率.减小方法之间的响应时间.降低方法之间的耦合度.= =!  (讲那么多,然而并没有什么卵用~) 第一章 学习目的: 通过一个小例子.了解重构在代码中的表现形式.说白了就是对重构能有一点感觉.…

原文地址: PHP 杂谈<重构-改善既有代码的设计>之一 重新组织你的函数 思维导图   点击下图,可以看大图.    介绍   我把我比较喜欢的和比较关注的地方写下来和大家分享.上次我写了篇<php 跟老大的对话>.还是有很多疑问,这书帮了我不少的忙.   如果你比较繁忙,或者懒得看文字,建议你直接看截图,也会有很大的收获的.你可以通过比较截图中的代码就能知道孰优孰劣了.   代码部分我为什么用图呢?因为我经常用手机看代码,博客园的代码在手机里乱七八糟的,还是看图比较舒服.  …

此文写得有点晚,记得去年7月读完的这本书,只是那时没有写文章的意识,也无所谓总结了,现在稍微聊一下吧. 想起写这篇感想,还是前几天看了这么一篇文章 研究发现重构软件并不会改善代码质量 先从一个大家都有的经历说起吧. 刚开始学编程时,比如,要统计数字出现的次数,我们会这么定义变量 int i=0;//统计次数 老师看了说,代码要有可读性,见名知意; 于是,我们把它改成 int count=0; 后来才知道,原来这么一手这就是重构的第一式,重命名 (eclipse快捷键 alt+shift+R,最近…

<重构--改善既有代码的设计>[PDF]下载链接: https://u253469.ctfile.com/fs/253469-231196358 编辑推荐 重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码.多年前,正是<重构:改善既有代码的设计>原版的出版,使重构终于从编程高手们的小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分.<重构:改善既有代码的设计>也因此成为与<设计模式>齐名的经典著作,被译为中.德.俄.日等众多语言,…

第1章 重构, 第一个案例 1.1 起点 1.2 重构的第一步 1.3 分解并重组 statement() 1.4 运用多态取代与价格相关的条件逻辑 1.5 结语 第2章 重构原则 2.1 何谓重构 2.2 为何重构 2.3 何时重构 2.4 怎么对经理说 2.5 重构的难题 2.6 重构与设计 2.7 重构与性能 2.8 重构与性能 2.9 重构起源何处 第3章 代码的坏味道 3.1 Duplicated Code (重复代码) 3.2 Long Method (过长函数) 3.3 Large…