当前位置:天才代写 > tutorial > JAVA 教程 > 用JBuilder 2005实现重构之认识重构

用JBuilder 2005实现重构之认识重构

2017-11-12 08:00 星期日 所属: JAVA 教程 浏览:307

副标题#e#

为什么要重构

从Martin Fowler所著的《重构–改进既有代码的设计》一书持续两年成为最脱销的计较机图书之一,就可以知道重构给措施员所带来的欣喜水平了。

那么什么是重构呢?重构就是在不改变软件现有成果的基本上,通过调解措施代码改进软件的质量、机能,使其措施的设计模式和架构更趋公道,提高软件的扩展性和维护性。

也许有人会问,为什么不在项目开始时多花些时间把设计做好,而要今后花时间来重构呢?要知道一个完美得可以预见将来任何变革的设计,或一个机动得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大偏向予以把控,而无法知道每个细枝末节,其次永远稳定的就是变革,提出需求的用户往往要在软件成型后,始才开始"品头论足",系统设计人员究竟不是先知先觉的神仙,成果的变革导致设计的调解再所不免。所以"测试为先,一连重构"作为精采开拓习惯被越来越多的人所采用,测试和重构像黄河的护堤,成为担保软件质量的瑰宝。

通过重构可以到达以下的方针:

·一连偏纠和改造软件设计

重构和设计是相辅相成的,它和设计互相互补。有了重构,你仍然必需做预先的设计,可是不必是最优的设计,只需要一个公道的办理方案就够了,假如没有重构、措施设计会逐渐糜烂变质,愈来愈像断线的鹞子,脱缰的野马无法节制。重构其实就是整理代码,让所有带着发散倾向的代码回归本位。

·使代码更易为人所领略

Martin Flower在《重构》中有一句经典的话:"任何一个傻瓜都能写出计较机可以领略的措施,只有写出人类容易领略的措施才是优秀的措施员。"对此,笔者感伤很深,有些措施员老是可以或许快速编写出可运行的代码,但代码中艰涩的定名使人晕眩得需要紧握坐椅扶手,试想一个新兵到来接办这样的代码他会不会想当逃兵呢?

软件的生命周期往往需要多批措施员来维护,我们往往忽略了这些厥后人。为了使代码容易被他人领略,需要在实现软件成果时做很多特另外事件,如清晰的排版机关,简明简要的注释,个中定名也是一个重要的方面。一个很好的步伐就是回收暗喻定名,即以工具实现的成果的依据,用形象化或拟人化的手法举办定名,一个很好的立场就是将每个代码元素像新生儿一样定名,也许笔者有点定名偏执狂的倾向,如能荣此雅号,将深以此为幸。

对付那些让人布满苍茫感甚至误导性的定名,需要果决地、大刀阔斧地整容,永远不要手下包涵!

·辅佐发明埋没的代码缺陷

孔子说过:温故而知新。重构代码时欺压你加深领略原先所写的代码。笔者常有写下措施后,却产生对本身的措施逻辑不甚领略的情景,曾为此惊悚过,厥后发明这种症状居然是很多措施员常患的"伤风"。当你也产生这样的景象时,通过重构代码可以加深对原设计的领略,发明个中的问题和隐患,构建出更好的代码。

·从久远来看,有助于提高编程效率

当你发明办理一个问题变得异常巨大时,往往不是问题自己造成的,而是你用错了要领,拙劣的设计往往导致臃肿的编码。

改进设计、提高可读性、淘汰缺陷都是为了稳住阵脚。精采的设计是乐成的一半,停下来通过重构改造设计,或者会在当前减缓速度,但它带来的后发优势却是不行低估的。

何时着手重构

新官上任三把火,开始一个全新的项目时,措施员往往也会燃起三把火:紧锣密鼓、脚不断蹄、加班加点,一支声势浩荡的千军万"码"夹裹着措施员豪情和扣击键盘的鸣金奋力前行,长驱直入,攻城掠地,直指"黄龙府"。

开拓司理是这支浩浩汤汤代码步队的统帅,他认真这支步队的运气,当齐恒公站在山顶上看到管仲练习的步队整齐划一地前进时,他叹息说"我有这样一支部队那边还怕没有胜利呢?"。但很遗憾,你手中的这支步队原本只是散兵游勇,在前进中招兵买马,不绝壮大,所以步队变形在所不免。当开拓司理觉察步队变形时,也许就是禁止住攻陷前方山头的诱惑,停下脚步整顿步队的时候了。

Kent Beck提出了"代码坏味道"的说法,和我们所提出的"步队变形"是同样的意思,步队变形的信号是什么呢?以下列述的代码症状就是"步队变形"的强烈信号:


#p#副标题#e#

·代码中存在反复的代码

中国有118 家整车出产企业,数量险些便是美、日、欧所有汽车厂家数之和,可是全国的年产量却不及一个外国大汽车公司的产量。反复建树只会导致效率的低效和资源的挥霍。

#p#分页标题#e#

措施代码更是不能搞反复建树,假如同一个类中有沟通的代码块,请把它提炼成类的一个独立要领,假如差异类中具有沟通的代码,请把它提炼成一个新类,永远不要反复代码。

·过大的类和过长的要领

过大的类往往是类抽象不公道的功效,类抽象不公道将低落了代码的复用率。要领是类王国中的诸侯国,诸侯国太局面必动摇中央集权。过长的要领由于包括的逻辑过于巨大,错误机率将直线上升,而可读性则直线下降,类的结实性很容易被冲破。当看到一个过长的要领时,需要想步伐将其分别为多个小要领,以便于分而治之。

·牵一毛而需要动全身的修改

当你发明修改一个小成果,或增加一个小成果时,就激发一次代码地动,也许是你的设计抽象度不足抱负,成果代码过分度手所引起的。

·类之间需要过多的通讯

A类需要挪用B类的过多要了解见B的内部数据,在干系上这两个类显得有点狎昵,大概这两个类本应该在一起,而不该该分居。

·太过耦合的信息链

"计较机是这样一门科学,它相信可以通过添加一其中间层办理任何问题",所以往往中间层会被过多地追加到措施中。假如你在代码中看到需要获取一个信息,需要一个类的要领挪用另一个类的要领,层层挂接,就象输油管一样节节相连。这往往是因为跟尾层太多造成的,需要查察就否有可移除的中间层,或是否可以提供更直接的挪用要领。

·各立山头干革命

假如你发明有两个类或两个要领固然定名差异但却拥有相似或沟通的成果,你会发明往往是因为开拓团队成员协调不足造成的。笔者曾经写了一个颇好用的字符串处理惩罚类,但因为没有实时告示团队其他人员,厥后发明项目中居然有三个字符串处理惩罚类。革命资源是贵重的,我们不该各立山头干革命。

·不完美的设计

在笔者刚完成的一个比对报警项目中,曾布置阿朱开拓报警模块,即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息,阿朱精彩地完成了这项任务。厥后用户又提出了及时比对的需求,即要求第三方系统以报文形式向比对报警系统发送请求,比对报警系统吸收并响应这个请求。这又需要用到Socket报文通讯,由于本来的设计没有将报文通讯模块独立出来,所以无法复用阿朱开拓的代码。厥后我实时调解了这个设计,新增了一个报文收发模块,使系统所有的对外通讯都复用这个模块,系统的整体设计也显得越发公道。

每个系统都或多或少存在不完美的设计,刚开始大概留意不到,到厥后才会逐步凸显出来,此时唯有勇于变动才是最好的出路。

·缺少须要的注释

固然很多软件工程的书籍常提醒措施员需要防备过多注释,但这个担忧好象并没有什么须要。往往措施员更感乐趣的是成果实现而非代码注释,因为前者更能带来成绩感,所以代码注释往往不是过多而是过少,过于简朴。人的影象曲线下降的坡度是陡得吓人的,当过了一段时间后再转头补注释时,很容易产生"提笔忘字,愈言且止"的景象。

曾在网上看到过微软的代码注释,其详尽水平让人叹为观止,也从中体悟到了微软乐成的一个履历。

 

    关键字:

天才代写-代写联系方式