大话重构连载17:抽取方法的实践

说了那么多理论,我们来看看怎样使用抽取方法来重构遗留系统。如前所述,重构的过程首先是阅读程序代码,边阅读边整理程序。将功能相对独立的代码段放在一起,在前面加上注释。调整一些程序的顺序,将相关的代码尽量放在一起,但要保证程序执行的结果不会发生改变。比较典型的,将变量的定义与使用变量的代码放在一起。这个步骤比较实用,因为许多的遗留系统,其代码都有一个坏毛病,就是在程序开始时定义一大堆变量,但要弄清这些变量都用来做什么,却十分困难。边读边调整,将变量的定义逐渐迁移到使用它的代码段中,将大大提高代码可读性,你甚至会发现并简化一些变量。

前面的工作为抽取函数做好了准备,但你不必阅读和整理完所有的代码才开始抽取。许多遗留函数的大函数非常长,你可以整理一部分,就开始着手重构。比如,把刚才分段的代码段抽取出来,形成一个独立的函数。在这里,代码段与注释,是我们决定是否需要抽取成函数的重要标志之一。

在阅读过程中,许多长相相似的代码也是我们需要重视的重要代码。重复代码是许多遗留系统代码质量差的重要原因之一,因此提高代码复用就成为了代码优化一个重要的项目。整合大量重复的代码,将其提取到一个统一的函数中为其它各处所调用,是一个值得推荐的办法。因此,重复代码也是抽取函数的重要标志。

除此之外,一些块操作的语句,如条件语句、循环语句、try语句,都可能成为抽取函数的标志。最典型的就是if语句,包含在if语句中间的常常是一个相对独立的功能,譬如一次重构中,原代码长得像这样:

1     ......
2     if (cmd != null && cmd.equals("chkCard")){
3         //此处省略了500行
4     } else if (cmd != null && cmd.equals("chkIc")){
5         //此处省略了300行
6     } else if (cmd != null && cmd.equals("chkBuffer")){
7         //此处省略了1000行
8     }
9     ......

整个这段代码有数千行之多,但整体结果就是用这样的一系列if语句组成。随后,我将每个if语句中的代码都提取出来形成了各自的函数。它们被重构成这样:

 1     ......
 2     if (cmd != null && cmd.equals("chkCard")){
 3          byte[] ret = chkCard(reader);
 4          servletOutput(res, ret);
 5     } else if (cmd != null && cmd.equals("chkIc")){
 6          byte[] ret = chkIc(reader);
 7          servletOutput(res, ret);
 8     } else if (cmd != null && cmd.equals("chkBuffer")){
 9          byte[] ret = chkBuffer(reader);
10          servletOutput(res, ret);
11     }
12     ......

这样,原来if语句中的业务操作代码,就被抽取到chkCard(), chkIc(), chkBuffer()这样的函数中了。起初我们将if语句中的所有代码都抽取出来写入这些函数中,这是十分自然而然想到的办法。但随后发现这样需要将response作为参数传递给这些函数中,这样的设计不太好。因此,将代码还原回来重新重构,将写入response的操作写入到servletOutput()中了。整个过程如图5.1所示:

图5.1分解大函数的示例

完成了此次重构以后,我们原来这个超级大函数由数千行代码,缩减到了百来行代码,这是一个可喜的进步,函数变得结构清晰而易于阅读。但是,被抽取出来的新函数却依然庞大,它们有的会达到一千多行,阅读依然困难。这时我们运用“抽取方法”继续分解。比如这个chkCard(),它执行的是一大堆校验,每个校验其功能都相对独立。因此,我首先调整代码顺序,将每个校验的代码都独立成一段,在前面添加相应的注释。然后使用抽取方法,将校验抽取到一个一个函数中。

整个数千行代码的超级大函数,就这样原子裂变式地逐渐分解,最后分解成数十个函数。每个函数只有数十行代码,并通过注释标注它们的用途与参数、返回值含义。这样,一个起初难于阅读的函数,经过一系列重构,开始变得可以阅读了。是的,我们开始迈出了可喜地一步。但一个对象包含了数十个方法,这些方法被凌乱地堆砌在一起,没有层级、没有主次。最关键是,虽然每个方法都不大,但这个对象却包含数千行代码,依然显得臃肿。因此我们还需要后面的步骤继续重构。

大话重构连载首页:http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!

时间: 2024-10-10 23:41:27

大话重构连载17:抽取方法的实践的相关文章

大话重构连载首页

<大话重构>这本书是我写的第一本书,从今天起我将通过连载的形式逐渐跟大家分享. 这本书让你: 告别游击队转变为正规军. 远离劣质代码走向精妙设计 真正明确专业级的软件开发是如何的 真正明确重构是如何一步一步进行的 高效重构七步曲.面对实践不卡壳 让遗留系统维护不再是你的梦魇 读完这本书以后: 需求变更不再纠结.重构让你润物细无声地容纳它们 超越代码级的重构,从各个层面深度领略重构之美 自己主动化測试不再是梦想.重构让自己主动化測试走你 又一次审视熟悉而陌生的技术.将碎了一地的它们又一次铆合在一

大话重构连载8:盘点我们的重构工具箱

下面我们来盘点一下系统重构工具箱里都有什么,也就是看一看系统重构到底都有哪些方法.系统重构总是在不同层次上调整我们的代码,因此重构方法也就分为了多个层次.从总体上看,重构方法分为以下几个层次:方法的重构.对象的重构.对象间的重构.继承体系间的重构.组织数据的重构与体系架构的重构. 前面那个例子我们可以清楚地看到方法的重构过程.方法的重构往往发生在一个对象的内部,是对一个对象内部的优化.从这个例子中,我们首先看到了增加注释.调整顺序.重命名变量.进行分段等操作,这些虽然不是什么重构方法,却是我们进

大话重构连载18:最常见的问题

使用抽取方法,虽然道理十分简单,但实际操作起来却并不是那么容易的.完成抽取方法最大的困难,就是如何处理抽取函数与原函数的数据交换.如同将一颗大树从土壤里拔出来,盘根错节的根茎,那是剪不断理还乱.当代码还没有被抽取出来之前,它们与其它程序都是在一个函数的内部,因此各个代码段可以毫无顾忌地相互交互数据.但当我们将代码从原函数中抽取出来时,抽取出来的代码与原函数中的代码就形成了一道墙,要交换的数据只能通过参数与返回值进行交互,这将给我们带来诸多麻烦. 将代码从原函数中抽取出来,放进新的函数中,首先就会

大话重构连载15:采用Mock技术完成测试

第五次重构我们引入了数据库的设计,用户信息要从数据库中读取,问候语库存储在数据库中,并支持添加与更新.数据库的引入使自动化测试变得困难了,因为数据状态总是变化着的,而这种变化使得测试过程不能复现,这是我们不愿看到的.因此,我们在设计时将业务与数据库访问分离,形成了UserDao与GreetingRuleDao.此时,我们的设计应当遵从“依赖反转”原则,即将UserDao与GreetingRuleDao设计成接口,并编写它们的实现UserDaoImpl与GreetingRuleDaoImpl.这样

大话重构连载16:超级大函数

事情总是这样的:当我们对一个遗留系统一忍再忍,再忍,忍,还要忍--终于积攒到某一天,实在忍无可忍了,拍案而起,不能再忍了,重构!!!事情就这样发生了.然而,在这时你突然发现,重构的工作千头万绪,真不知从何开始.堆积如山的问题此起彼伏,期望修改的设计思绪万千.这里有个想法,那里有个思路,什么都想做,却什么都做不了,真是脑子里一团乱麻.这时候,没有一个合理的步骤,清晰的计划,瞎干蛮干是十分危险的,它会为你的重构带来不可预期的未来.无数次的经验告诉我,不论是什么系统,采用什么架构,从分解大函数开始,肯

大话重构连载7:重构是一系列的等量变换

系统重构要求我们对代码的每一步修改,都不能改变软件的外部行为,因此在系统重构中的所有方法,都是一种代码的等量变换.重构的过程,就好像在做数学题,一步一步地进行算式的等量变换.经过一系列等量变换,最终的结果虽然在形式上与原式不一样,但通过计算可以得到与原式完全相同的结果. 这种等量变换对于重构来说非常重要,它使得我们进行重构以后,程序还是那些程序,代码还是那些代码.但是,等量变换不等于原地踏步.正如矩阵通过等量变换可以得到方程组的解,微积分可以通过等量变换计算最终的结果,重构通过等量变换,在保证代

大话重构连载14:我们是这样自动化测试的

说了那么多,让我们用示例看看,系统重构是应该怎样做自动化测试的.还是回到前面那个HelloWorld的例子(详见 3.3 小步快跑是这样玩的),该类中有一个sayHello()方法,只要我们输入当前的时间与用户名,就返回对该用户的问候语.如果当前时间是上午,则返回"Hi, XXX. Good morning!":如果是下午,则返回"Hi, XXX. Good afternoon!":如果是晚上,则返回"Hi, XXX.Good Night!",这

大话重构连载5:软件修改的四种动机

软件,自从被我们开发出来并交付使用以后,如果它运行得好好的,我们是不会去修改它的.我们要修改软件,万变不离其宗,无非就是四种动机: 1. 增加新功能: 2. 原有功能有BUG: 3. 改善原有程序的结构: 4. 优化原有系统的性能[1]. 第一种和第二种动机,都是源于客户的功能需求,而第四种是源于客户的非功能需求. 软件的外部质量,其衡量的标准就是客户对软件功能需求与非功能需求的满意度.它涉及到一个企业.一个软件的信誉度与生命力,因此为所有软件企业所高度重视.但是,就在所有企业高管把软件外部质量

大话重构连载11:小步快跑是这样玩的

说了那么多.相信你对小步快跑的概念有了一个初步的印象,但理解还不是非常深.让我们来看一看一个实际工作中的样例,来亲身感受一下什么是大布局,什么是大设计.什么是小设计. 还是回到前面那个HelloWorld的样例,起初的需求总是简单而清晰的. 当用户登录一个站点时,站点往往须要给用户打一个招呼:"hi, XXX! ".同一时候,假设此时是上午则显示"Good morning! ",假设是下午则显示"Good afternoon! ",除此显示&qu