本节书摘来自异步社区《重构：改善既有代码的设计》一书中的第1章，第1.节，作者【美】Martin Fowler，更多章节内容可以访问云栖社区“异步社区”公众号查看。
第1章 重构，第一个案例
重构：改善既有代码的设计
我该从何说起呢？按照传统做法，一开始介绍某个东西时，首先应该大致讲讲它的历史、主要原理等等。可是每当有人在会场上介绍这些东西，总是诱发我的瞌睡虫。我的思绪开始游荡，我的眼神开始迷离，直到主讲人秀出实例，我才能够提起精神。实例之所以可以拯救我于太虚之中，因为它让我看见事情在真正进行。谈原理，很容易流于泛泛，又很难说明如何实际应用。给出一个实例，就可以帮助我把事情认识清楚。
所以我决定从一个实例说起。在此过程中我将告诉你很多重构的道理，并且让你对重构过程有一点感觉。然后我才能向你展开通常的原理介绍。
但是，面对这个介绍性实例，我遇到了一个大问题。如果我选择一个大型程序，那么对程序自身的描述和对整个重构过程的描述就太复杂了，任何读者都不忍卒读（我试了一下，哪怕稍微复杂一点的例子都会超过100页）。如果我选择一个容易理解的小程序，又恐怕看不出重构的价值。
和任何立志要介绍“应用于真实世界中的有用技术”的人一样，我陷入了一个十分典型的两难困境。我只能带引你看看如何在一个我所选择的小程序中进行重构，然而坦白说，那个程序的规模根本不值得我们那么做。但是如果我给你看的代码是大系统的一部分，重构技术很快就变得重要起来。所以请你一边观赏这个小例子，一边想象它身处于一个大得多的系统。
1.1 起点
实例非常简单。这是一个影片出租店用的程序，计算每一位顾客的消费金额并打印详单。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租赁时间和影片类型算出费用。影片分为三类：普通片、儿童片和新片。除了计算费用，还要为常客计算积分，积分会根据租片种类是否为新片而有不同。
我用了几个类来表现这个例子中的元素。图1-1是一张UML类图，用以显示这些类。
图1-1 本例一开始的各个类。此图只显示最重要的特性。图中所用符号是
UML（[Fowler，UML]）
我会逐一列出这些类的代码。
Movie（影片）
Movie只是一个简单的纯数据类。
public class Movie {
public static final int CHILDRENS = 2;
public static final int REGULAR = 0;
public static final int NEW_RELEASE = 1;
private String _title;
private int _priceCode;
public Movie(String title, int priceCode) {
_title = title;
_priceCode = priceCode;
}
public int getPriceCode() {
return _priceCode;
}
public void setPriceCode(int arg) {
_priceCode = arg;
}
public String getTitle (){
return _title;
};
}
Rental（租赁）
Rental表示某个顾客租了一部影片。
class Rental {
private Movie _movie;
private int _daysRented;
public Rental(Movie movie, int daysRented) {
_movie = movie;
_daysRented = daysRented;
}
public int getDaysRented() {
return _daysRented;
}
public Movie getMovie() {
return _movie;
}
}
Customer（顾客）
Customer类用来表示顾客。就像其他类一样，它也拥有数据和相应的访问函数：
class Customer {
private String _name;
private Vector _rentals = new Vector();
public Customer (String name){
_name = name;
};
public void addRental(Rental arg) {
_rentals.addElement(arg);
}
public String getName (){
return _name;
};
Customer还提供了一个用于生成详单的函数，图1-2显示这个函数带来的交互过程。完整代码显示于下一页。
public String statement() {
double totalAmount = 0;
int frequentRenterPoints = 0;
Enumeration rentals = _rentals.elements();
String result = "Rental Record for " + getName() + "\n";
while (rentals.hasMoreElements()) {
double thisAmount = 0;
Rental each = (Rental) rentals.nextElement();
//determine amounts for each line
switch (each.getMovie().getPriceCode()) {
case Movie.REGULAR:
thisAmount += 2;
if (each.getDaysRented() > 2)
thisAmount += (each.getDaysRented() - 2) * 1.5;
break;
case Movie.NEW_RELEASE:
thisAmount += each.getDaysRented() * 3;
break;
case Movie.CHILDRENS:
thisAmount += 1.5;
if (each.getDaysRented() > 3)
thisAmount += (each.getDaysRented() - 3) * 1.5;
break;
}
// add frequent renter points
frequentRenterPoints ++;
// add bonus for a two day new release rental
if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) &&
each.getDaysRented() > 1) frequentRenterPoints ++;
//show figures for this rental
result += "\t" + each.getMovie().getTitle()+ "\t" +
String.valueOf(thisAmount) + "\n";
totalAmount += thisAmount;
}
//add footer lines
result += "Amount owed is " + String.valueOf(totalAmount) + "\n";
result += "You earned " + String.valueOf(frequentRenterPoints)+
" frequent renter points";
return result;
}
对此起始程序的评价
这个起始程序给你留下什么印象？我会说它设计得不好，而且很明显不符合面向对象精神。对于这样一个小程序，这些缺点其实没有什么大不了的。快速而随性地设计一个简单的程序并没有错。但如果这是复杂系统中具有代表性的一段，那么我就真的要对这个程序信心动摇了。Customer里头那个长长的statement()做的事情实在太多了，它做了很多原本应该由其他类完成的事情。
即便如此，这个程序还是能正常工作。所以这只是美学意义上的判断，只是对丑陋代码的厌恶，是吗？如果不去修改这个系统，那么的确如此，编译器才不会在乎代码好不好看呢。但是当我们打算修改系统的时候，就涉及了人，而人在乎这些。差劲的系统是很难修改的，因为很难找到修改点。如果很难找到修改点，程序员就很有可能犯错，从而引入bug。
在这个例子里，我们的用户希望对系统做一点修改。首先他们希望以HTML格式输出详单，这样就可以直接在网页上显示，这非常符合时下的潮流。现在请你想一想，这个变化会带来什么影响。看看代码你就会发现，根本不可能在打印HTML报表的函数中复用目前statement()的任何行为。你唯一可以做的就是编写一个全新的htmlStatement()，大量重复statement()的行为。当然，现在做这个还不太费力，你可以把statement()复制一份然后按需要修改就是了。
但如果计费标准发生变化，又会如何？你必须同时修改statement()和htmlStatement()，并确保两处修改的一致性。当你后续还要再修改时，复制粘贴带来的问题就浮现出来了。如果你编写的是一个永不需要修改的程序，那么剪剪贴贴就还好，但如果程序要保存很长时间，而且可能需要修改，复制粘贴行为就会造成潜在的威胁。
现在，第二个变化来了：用户希望改变影片分类规则，但是还没有决定怎么改。他们设想了几种方案，这些方案都会影响顾客消费和常客积分点的计算方式。作为一个经验丰富的开发者，你可以肯定：不论用户提出什么方案，你唯一能够获得的保证就是他们一定会在六个月之内再次修改它。
为了应付分类规则和计费规则的变化，程序必须对statement()做出修改。但如果我们把statement()内的代码复制到用以打印HTML详单的函数中，就必须确保将来的任何修改在两个地方保持一致。随着各种规则变得越来越复杂，适当的修改点越来越难找，不犯错的机会也越来越少。
你的态度也许倾向于尽量少修改程序：不管怎么说，它还运行得很好。你心里牢牢记着那句古老的工程谚语：“如果它没坏，就不要动它。”这个程序也许还没坏掉，但它造成了伤害。它让你的生活比较难过，因为你发现很难完成客户所需的修改。这时候，重构技术就该粉墨登场了。
未标题-1
如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。