### 起点
实例非常简单。这是一个影片出租店用的程序，计算每一位顾客的消费金额并打印报表（statement）。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租赁时间和影片类型算出费用。影片分为三类：普通片、儿童片和新片。除了计算费用，还要为常客计算点数；点数会随着「租片种类是否为新片」而有不同。
我以数个classes 表现这个例子中的元素。图1.1是一张UML class diagram（类图），用以显示这些classes 。我会逐一列出这些classes 的代码。
图1.1 本例一开始的各个classes 。此图只显示最重要的特性。图中所用符号是UML（Unified Modeling Language ，统一建模语言，[Fowler, UML])。
**Movie（影片）**
Movie只是一个简单的data class（纯数据类）。
~~~
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 表示「某个顾客租了一部影片」。
~~~
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 用来表示顾客。就像其他classes一样，它也拥有数据和相应的访问函数（accessor）：
~~~
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「还提供了一个用以制造报表的函数（method），图1.2显示这个函数带来的交互过程（interactions ）。完整代码显示于下一页。
图1.2 statement() 的交互过程（interactions 。
~~~
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;
}
~~~
**对此起始程序的评。**
这个起始程序给你留下什么印象？我会说它设计得不好，而且很明显不符合面向对象精神。对于这样一个小程序，这些缺点其实没有什么关系。快速而随性（quick and dirty ）地设计一个简单的程序并没有错。但如果这是复杂系统中具有代表性的一段， 那么我就真的要对这个程序信心动摇了。Customer 里头那个长长的statement() 做的事情实在太多了，它做了很多原本应该由其他完成的事情。
即便如此，这个程序还是能正常工作。所以这只是美学意义上的判断，只是对丑陋代码的厌恶，是吗？在我们修改这个系统之前的确如此。编译器才不会在乎代码好不好看呢。但是当我们打算修改系统的时候，就涉及到了人，而人在乎这些。差劲的系统是很难修改的，因为很难找到修改点。如果很难找到修改点，程序员就很有可能犯错，从而引入「臭虫」（bugs）。
在这个例子里，我们的用户希望对系统做一点修改。首先他们希望以HTML 格式打印报表，这样就可以直接在网页上显示，这非常符合潮流。现在请你想一想，这个变化会带来什么影响。看看代码你就会发现，根本不可能在打印报表的函数中复用（reuse）目前statement() 的任何行为。你惟一可以做的就是编写一个全新的htmlStatement() ，大量重复statement() 的行为。当然，现在做这个还不太费力，你可以把statement() 复制一份然后按需要修改就是。
但如果计费标准发生变化，又会发生什么事？你必须同时修改statement() 和htmlstatement() ，并确保两处修改的一致性。当你后续还要再修改时，剪贴（copy-paste）问题就浮现出来了。如果你编写的是一个永不需要修改的程序，那么剪剪贴贴就还好，但如果程序要保存很长时间，而且可能需要修改，剪贴行为就会造成潜在的威胁。
现在，第二个变化来了：用户希望改变影片分类规则，但是还没有决定怎么改。他 们设想了几种方案，这些方案都会影响顾客消费和常客积点的计算方式。作为一个经验丰富的开发者，你可以肯定：不论用户提出什么方案，你惟一能够获得的保证就是他们一定会在六个月之内再次修改它。
为了应付分类规则和计费规则的变化，程序必须对statement() 作出修改。但如果我们把statement() 内的代码拷贝到用以打印报表的函数中，我们就必须确保将来的任何修改在两个地方保持一致。随着各种规则变得愈来愈复杂，适当的修改点愈来愈难找，不犯错的机会也愈来愈少。
你的态度也许倾向于「尽量少修改程序」：不管怎么说，它还运行得很好。你心里头牢牢记着那句古老的工程学格言：「如果它没坏，就别动它」。这个程序也许还没坏掉，但它带来了伤害。它让你的生活比较难过，因为你发现很难完成客户所需的修改。这时候就该重构技术粉墨登场了。
TIP：如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地那么做，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
- 译序 by 侯捷
- 译序 by 熊节
- 序言
- 前言
- 章节一 重构，第一个案例
- 起点
- 重构的第一步
- 分解并重组statement()
- 运用多态（Polymorphism）取代与价格相关的条件逻辑
- 结语
- 章节二 重构原则
- 何谓重构
- 为何重构
- 「重构」助你找到臭虫(bugs)
- 何时重构
- 怎么对经理说？
- 重构的难题
- 重构与设计
- 重构与性能（Performance）
- 重构起源何处？
- 章节三 代码的坏味道
- Duplicated Code（重复的代码）
- Long Method（过长函数）
- Large Class（过大类）
- Long Parameter List（过长参数列）
- Divergent Change（发散式变化）
- Shotgun Surgery（散弹式修改）
- Feature Envy（依恋情结）
- Data Clumps（数据泥团）
- Primitive Obsession（基本型别偏执）
- Switch Statements（switch惊悚现身）
- Parallel Inheritance Hierarchies（平行继承体系）
- Lazy Class（冗赘类）
- Speculative Generality（夸夸其谈未来性）
- Temporary Field（令人迷惑的暂时值域）
- Message Chains（过度耦合的消息链）
- Middle Man（中间转手人）
- Inappropriate Intimacy（狎昵关系）
- Alternative Classes with Different Interfaces（异曲同工的类）
- Incomplete Library Class（不完美的程序库类）
- Data Class（纯稚的数据类）
- Refused Bequest（被拒绝的遗贈）
- Comments（过多的注释）
- 章节四 构筑测试体系
- 自我测试代码的价值
- JUnit测试框架
- 添加更多测试
- 章节五 重构名录
- 重构的记录格式
- 寻找引用点
- 这些重构准则有多成熟
- 章节六 重新组织你的函数
- Extract Method（提炼函数）
- Inline Method（将函数内联化）
- Inline Temp（将临时变量内联化）
- Replace Temp with Query（以查询取代临时变量）
- Introduce Explaining Variable（引入解释性变量）
- Split Temporary Variable（剖解临时变量）
- Remove Assignments to Parameters（移除对参数的赋值动作）
- Replace Method with Method Object（以函数对象取代函数）
- Substitute Algorithm（替换你的算法）
- 章节七 在对象之间搬移特性
- Move Method（搬移函数）
- Move Field（搬移值域）
- Extract Class（提炼类）
- Inline Class（将类内联化）
- Hide Delegate（隐藏「委托关系」）
- Remove Middle Man（移除中间人）
- Introduce Foreign Method（引入外加函数）
- Introduce Local Extension（引入本地扩展）
- 章节八 重新组织数据
- Self Encapsulate Field（自封装值域）
- Replace Data Value with Object（以对象取代数据值）
- Change Value to Reference（将实值对象改为引用对象）
- Replace Array with Object（以对象取代数组）
- Replace Array with Object（以对象取代数组）
- Duplicate Observed Data（复制「被监视数据」）
- Change Unidirectional Association to Bidirectional（将单向关联改为双向）
- Change Bidirectional Association to Unidirectional（将双向关联改为单向）
- Replace Magic Number with Symbolic Constant（以符号常量/字面常量取代魔法数）
- Encapsulate Field（封装值域）
- Encapsulate Collection（封装群集）
- Replace Record with Data Class（以数据类取代记录）
- Replace Type Code with Class（以类取代型别码）
- Replace Type Code with Subclasses（以子类取代型别码）
- Replace Type Code with State/Strategy（以State/strategy 取代型别码）
- Replace Subclass with Fields（以值域取代子类）
- 章节九 简化条件表达式
- Decompose Conditional（分解条件式）
- Consolidate Conditional Expression（合并条件式）
- Consolidate Duplicate Conditional Fragments（合并重复的条件片段）
- Remove Control Flag（移除控制标记）
- Replace Nested Conditional with Guard Clauses（以卫语句取代嵌套条件式）
- Replace Conditional with Polymorphism（以多态取代条件式）
- Introduce Null Object（引入Null 对象）
- Introduce Assertion（引入断言）
- 章节十一 处理概括关系
- Pull Up Field（值域上移）
- Pull Up Method（函数上移）
- Pull Up Constructor Body（构造函数本体上移）
- Push Down Method（函数下移）
- Push Down Field（值域下移）
- Extract Subclass（提炼子类）
- Extract Superclass（提炼超类）
- Extract Interface（提炼接口）
- Collapse Hierarchy（折叠继承关系）
- Form Template Method（塑造模板函数）
- Replace Inheritance with Delegation（以委托取代继承）
- Replace Delegation with Inheritance（以继承取代委托）
- 章节十二 大型重构
- 这场游戏的本质
- Tease Apart Inheritance（梳理并分解继承体系）
- Convert Procedural Design to Objects（将过程化设计转化为对象设计）
- Separate Domain from Presentation（将领域和表述/显示分离）
- Extract Hierarchy（提炼继承体系）
- 章节十三 重构，复用与现实
- 现实的检验
- 为什么开发者不愿意重构他们的程序？
- 现实的检验（再论）
- 重构的资源和参考资料
- 从重构联想到软件复用和技术传播
- 结语
- 参考文献
- 章节十四 重构工具
- 使用工具进行重构
- 重构工具的技术标准（Technical Criteria ）
- 重构工具的实用标准（Practical Criteria ）
- 小结
- 章节十五 集成
- 参考书目