系统的重构.docVIP

为什么重构? 重构是指在不改变程序功能的前提下改变其结构。重构是一项功能强大的技术，但是执行起来需要倍加小心才行。主要的危险在于可能在不经意中引入一些错误，尤其是在进行手工重构的时候更是如此。这种危险引发了对重构技术的普遍批评：当代码不会崩溃的时候为什么要修改它呢？ 您需要进行代码重构的原因可能有以下几个：传说中的第一个原因是：需要继承为某个古老产品而开发的年代久远的代码，或者突然碰到这些代码。最初的开发团队已经不在了。我们必须创建增加了新特性的新版本软件，但是这些代码已经无法理解了。新的开发队伍夜以继日地工作，破译代码然后映射代码，经过大量的规划与设计之后，人们将这些代码分割成碎片。历经重重磨难之后，所有这些东西都按照新版本的要求归位了。这是英雄般的重构故事，几乎没有人能在经历了这些之后活着讲述这样的故事。 还有一种现实一些的情况是项目中加入了新的需求，需要对设计进行修改。至于是因为在最初的规划过程中失察，还是由于采用了迭代式的开发过程（比如敏捷开发，或者是测试驱动的开发）而在开发过程中有意引入需求，这两者并没有实质性的区别。这样的重构的规模要小得多，其内容一般涉及通过引入接口或者抽象类来更改类的继承关系，以及对类进行分割和重新组织，等等。 重构的最后一个原因是，当存在可用的自动重构工具时，可以有一个用来预先生成代码的快捷方式——就好比在您无法确定如何拼写某个单词的时候，可以用某种拼写检查工具输入这个单词。比如说，您可以用这种平淡无奇的重构方法生成 getter 和 setter 方法，一旦熟悉了这样的工具，它就可以为您节省很多的时间。 Eclipse 的重构工具无意进行英雄级的重构——适合这种规模的工具几乎没有——但是不论是否用到敏捷开发技术，Eclipse 的工具对于一般程序员修改代码的工作都具有无法衡量的价值。毕竟任何复杂的操作只要能够自动进行，就可以不那么烦闷了。只要您知道 Eclipse 实现了什么样的重构工具，并理解了它们的适用情况，您的生产力就会得到极大的提高。 要降低对代码造成破坏的风险，有两种重要的方法。第一种方法是对代码进行一套完全彻底的单元测试：在重构之前和之后都必须通过这样的测试。第二种方法是使用自动化的工具来进行重构，比如说 Eclipse 的重构特性。 将彻底的测试与自动化重构结合起来就会更加有效了，这样重构也就从一种神秘的艺术变成了有用的日常工具。为了增加新的功能或者改进代码的可维护性，我们可以在不影响原有代码功能的基础上迅速且安全地改变其结构。这种能力会对您设计和开发代码的方式产生极大的影响，即便是您没有将其结合到正式的敏捷方法中也没有关系。 Eclipse 中重构的类型 Eclipse 的重构工具可以分为三大类（下面的顺序也就是这些工具在 Refactoring 菜单中出现的顺序）： 对代码进行重命名以及改变代码的物理结构，包括对属性、变量、类以及接口重新命名，还有移动包和类等。 改变类一级的代码逻辑结构，包括将匿名类转变为嵌套类，将嵌套类转变为顶级类、根据具体的类创建接口，以及从一个类中将方法或者属性移到子类或者父类中。 改变一个类内部的代码，包括将局部变量变成类的属性、将某个方法中选中部分的代码变成一个独立的方法、以及为属性生成 getter 和 setter 方法。 还有几个重构工具并不能完全归入这三个种类，特别是 Change Method Signature，不过在本文中还是将这个工具归入第三类。除了这种例外情况以外，本文下面几节都是按照上面的顺序来讨论 Eclipse 重构工具的。 物理重组与重命名 显然，您即便没有特别的工具，也可以在文件系统中重命名文件或者是移动文件，但是如果操作对象是 Java 源代码文件，您就需要编辑很多文件，更新其中的 import 或 package 语句。与此类似，用某种文本编辑器的有哪些信誉好的足球投注网站与替换功能也可以很容易地给类、方法和变量重新命名，但是这样做的时候必须十分小心，因为不同的类可能具有名称相似的方法或者变量；要是从头到尾检查项目中所有的文件，来保证每个东西的标识和修改的正确性，那可真够乏味的。 Eclipse 的 Rename 和 Move 工具能够十分聪明地在整个项目中完成这样的修改，而不需要用户的干涉。这是因为 Eclipse 可以理解代码的语义，从而能够识别出对某个特定方法、变量或者类名称的引用。简化这一任务有助于确保方法、变量和类的名称能够清晰地指示其用途。 我们经常可以发现代码的名字不恰当或者令人容易误解，这是因为代码与最初设计的功能有所不同。比方说，某个用来在文件中查找特定单词的程序也许会扩展为在 Web 页面中通过 URL 获取 InputStream 的操作。如果这一输入流最初叫做 file ，那么就应该修改它的名字，以便能反