JBuilder2005实现重构之杂项重构

1、优化import

简而言之,通过优化import的设置可以达到以下的目的:

去除无用的import语句:如在类中没有使用任何包中的类,则这个包的import语句可以删除。

设置包的阈值:当前类引用包中类的数目大于这个阈值时,引入整个包(如import java.io.*),否则为包中每个被引用的类单独指定的一个import语句(如import java.io.File)。

设置包的排列顺序:按照一般的习惯,按包的常用程度从高到低进行排列,常用的包放在前面引入。一般情况下,JDK经典的包放在最前面(以java.为前缀),JDK扩展包紧跟其后(以javax.为前缀),接着是第三方类库包(如org.apache.*),再次是自己开发的公用类库,最后才是工程中的其他类。

通过Project->Project Properties...->Java Formating->在Imports设置页中切换到Threshold标


图25 设置包阈值对话框

签页中通过Package import threshold指定包的阈值,默认为0表示进行优化import后,用通配符以整个包的形式分别引入。

你也可以勾选Always import classes项,将每个类用单独的import语句引入,这相当于将Package import threshold设置为无穷大。

在Imports设置页中切换到Sort Order标签页,在此指定import代码段的包引入顺序及格式。假设myrefactor.jpx工程中有一个myrefactor.sub1的子包,我们通过以下步骤将其置为import引入代码段的最后,并在前面添加一个空行:

1) 点击Add blank line在列表中添加一个<blank line>,表示在import代码段中添加一个空行。

2) 点击Add prefix...在弹出的Add Prefix对话框中选择myrefactor.sub1包。

3) 点击OK保存设置。


图26 import代码段样式设置对话框

此外,还可以通过Move Up和Move Down调整包在引入代码段中的位置。列表中有一个<*>项,表示其他所有未匹配的包,如有一个以com.打开的包就放置在<*>的位置。

设置完后,在工程窗格的<Project Source>节点上右击,选择Format Package...在弹出的Fomcat Code对话框中确认选择Optimize imports项,按OK后,JBuilder对工程中所有的类进行import代码段进行优化重构。

时间: 2024-08-25 14:07:07

JBuilder2005实现重构之杂项重构的相关文章

JBuilder2005实现重构之对重构的支持

Martin Flower在写<重构>时曾经感叹地说,如果有一个自动化的重构工具出现就好了,而且也预言了重构的发展方向是工具自动化重构.JBuilder正好迎合了这声呼喊,到目前为此,可以很公允地说,还没有一种工具在重构的表现上可望其项背. 1.提供了哪些重构的功能 JBuilderX(上一版本)就已经有了重构的功能,JBuilder 2005对代码重构投入了更多的热情,赋予了更多灵活易用的功能.在JBuilder 2005中,重构已经单独形成一个独立的Refactor主菜单.简要的讲JBui

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

为什么要重构 从Martin Fowler所著的<重构--改善既有代码的设计>一书连续两年成为最畅销的计算机图书之一,就可以知道重构给程序员所带来的欣喜程度了. 那么什么是重构呢?重构就是在不改变软件现有功能的基础上,通过调整程序代码改善软件的质量.性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性. 也许有人会问,为什么不在项目开始时多花些时间把设计做好,而要以后花时间来重构呢?要知道一个完美得可以预见未来任何变化的设计,或一个灵活得可以容纳任何扩展的设计是不存在的.系统设计人

领导重构代码,重构一堆的bug,怎么办 ?

问题描述 领导重构代码,重构一堆的bug,怎么办 ? 本来测试通过领导重构代码,重构一堆的bug,页面都给换了?怎么办 解决方案 领导说什么就是什么,不要自作主张 解决方案二: 重构代码,有bug就修正呗.

JBuilder2005实现重构之分布式重构

由于软件工程的复杂性,一个大型的软件常常被切割成不同的子软件模块,并由不同的团队承担.假设一个大型的软件分为三个子模块: ·A模块:底层处理类模块. ·B模块:高层业务模块1. ·C模块:高层业务模块2. A模块作为底层的模块,会被B和C模块调用,但因为A模块由单独的团队开发(在JBuilder中表现为单独的工程),A模块的重构仅在当前工程中进行.JBuilder会记录重构轨迹,并允许你通过JAR档案包含这些重构的记录,当B及C模块工程通过工程类库重新引入A的JAR档案文件时,可以将在A工程中的

浅谈遗留代码的重构

             背景 <重构>诞生至今有近17个年头了,日常开发中大家谈到重构,要么非常随意,认为重构就是改代码:要么非常谨慎,把重构描述成焦油坑,像瘟神一样敬而远之.针对最具挑战性的遗留代码重构,有哪些需要注意的呢? 谈论任何事情,都该有它的上下文.本文谈论的技术背景是大型通信类产品,对于互联网产品不一定适用.另外,本文也不会涉及重构技术,有兴趣读者可以读<重构>或者<Effective Refactoring in C++>. 遗留代码重构决策表 遗留代码

对“重构”适用范围的思考

<重构>一书写的非常好,让我大大开阔了思路,认识到对代码的修改是一个可量化.可重复的过程,软件业中最缺乏的好像就是可量化和可重复的过程. 但是和大多数介绍方法论的书相似,这本书并未对重构的适用范围进行探讨,更没有对现实中软件编码工作中重构的作用和地位做出评价.当然也许这两个问题太过广泛,不容易下一个定论.这篇文章希望能对重构适用的范围和重构在软件开发过程中的位置进行一番探讨,权作抛砖引玉. 以下是对重构的受限范围作的一个思考: 1.对局部代码的重构与对设计的重构是两个完全不同的领域.虽然大规模

重构是一系列的等量变换

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

重构连载之一个真实的谎言

经过前面的一番讲解,相信你已经对系统重构有了一些初步的认识了.一切的一切仿佛在告诉我们,系统重构总是与需求变更无关.但此时,我不得不告诉你这是真实的谎言. 我们的软件系统总是处于一种变化之中,并且往往是一种由浅入深.由易到难的过程.但是,当系统复杂程度发生变化时,我们应当及时调整我们的设计,来适应新的变化.然而我们没有做到这一点,所以我们的系统维护变得越来越困难.要解决我们的问题必须通过系统重构去优化我们的程序,使之重新适应业务需求.毫无疑问,需求变更才是我们去重构的主要动因. 然而,系统重构要

重构连载之大布局与小步快跑

以往我们在重新设计一个系统时,总是喜欢大布局.全面地整理系统需求,全面地分析系统功能,再全面地设计系统.开发.测试.这样一个过程往往会持续数月,花费大量的工作量.但是,不到最后设计出来,谁都不知道会不会存在问题.这就是"大布局"的弊病. 正因为如此,软件大师在讲述系统重构时总是强调,系统重构应当避免大设计,而应当尽量采用一个一个连续不断的小设计.这就是我们所说的"小步快跑"的设计模式. 小步快跑体现出了敏捷软件开发的特点--简单与快速反馈.不要想得太多了,活在今天的