oyhk 学习笔记
对于重构,大家应该都一些认识了吧...下面一个小例子,让你们感觉感觉代码重构是什么
下一篇文章:java 代码重构-第一章(分解并重组statement())
1.1 起点
-
实例非常简单。这是一个影片出租店用的程序,计算每一位顾客的消费金额并打印报表(statement)。操作者告诉程序:顾客租了哪些影片、租期多长,程序便根据租赁时间和影片类型算出费用。影片分为三类:普通片、儿童片和新片。除了计算费用,还要为常客计算点数;点数会随着「租片种类是否为新片」而有不同。
- 我以数个classes 表现这个例子中的元素。图1.1是一张UML class diagram(类图),用以显示这些classes 。我会逐一列出这些classes 的代码。
Movie (影片) movie 只是一个简单的纯数据类.package com.mkfree.refactoring.shap1;
/**
* 电影类
* @author hk
*
* 2012-12-25 下午10:55:14
*/
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 String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
public int getPriceCode() {
return priceCode;
}
public void setPriceCode(int priceCode) {
this.priceCode = priceCode;
}
}
Rental (租凭)
package com.mkfree.refactoring.shap1;
/**
* 租凭
* @author hk
*
* 2012-12-25 下午10:57:00
*/
public class Rental {
private Movie movie;
private int deysRented;
public Rental(Movie movie,int deysRented){
this.movie = movie;
this.deysRented = deysRented;
}
public Movie getMovie() {
return movie;
}
public int getDeysRented() {
return deysRented;
}
}
Customer (顾客)
package com.mkfree.refactoring.shap1;
import java.util.Enumeration;
import java.util.Vector;
/**
* 顾客
* @author hk
*
* 2012-12-25 下午10:59:03
*/
public class Customer {
private String name;
private Vector<Rental> rentals = new Vector<>();
public Customer(String name) {
this.name = name;
}
/**
* 添加
* @param rental
*/
public void addRentals(Rental rental){
rentals.add(rental);
}
public String getName() {
return name;
}
/**
* 通计清单
* @return
*/
public String statement(){
double totalAmount = 0;//合计
int frequentRentePoints = 0;
Enumeration<Rental> enu_rentals = rentals.elements();
String result = "Rental Record for "+ this.getName() + "
";
while(enu_rentals.hasMoreElements()){
double thisAmount = 0;
Rental each = enu_rentals.nextElement();
switch (each.getMovie().getPriceCode()) {
case Movie.REGULAR:
thisAmount += 2;
if(each.getDeysRented() > 2){
thisAmount += (each.getDeysRented() - 2) * 1.5;
}
break;
case Movie.NEW_RELEASE:
thisAmount += each.getDeysRented() * 3;
break;
case Movie.CHILDRENS:
thisAmount += 1.5;
if(each.getDeysRented() > 3){
thisAmount += (each.getDeysRented() -3 ) * 1.5;
}
break;
}
frequentRentePoints ++;
if((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) && each.getDeysRented() > 1){
frequentRentePoints ++;
}
result += " "+each.getMovie().getTitle() + " " +String.valueOf(thisAmount) + "
";
totalAmount += thisAmount;
}
result += "Amount owed is " + String.valueOf(totalAmount) + "
";
result += "You earned " + String.valueOf(frequentRentePoints) + " frequent renter points";
return result;
}
}
Customer 还提供了一个用于生成清单的函数,图1-2显示这个函数带来的交互过程
对此起始程序的评。
-
这个起始程序给你留下什么印象?我会说它设计得不好,而且很明显不符合面向对象精神。对于这样一个小程序,这些缺点其实没有什么关系。快速而随性(quick and dirty )地设计一个简单的程序并没有错。但如果这是复杂系统中具有代表性的一段, 那么我就真的要对这个程序信心动摇了。Customer 里头那个长长的statement() 做的事情实在太多了,它做了很多原本应该由其他完成的事情。
-
即便如此,这个程序还是能正常工作。所以这只是美学意义上的判断,只是对丑陋代码的厌恶,是吗?在我们修改这个系统之前的确如此。编译器才不会在乎代码好不好看呢。但是当我们打算修改系统的时候,就涉及到了人,而人在乎这些。差劲的系统是很难修改的,因为很难找到修改点。如果很难找到修改点,程序员就很有可能犯错,从而引入「臭虫」(bugs)。
-
在这个例子里,我们的用户希望对系统做一点修改。首先他们希望以HTML 格式打印报表,这样就可以直接在网页上显示,这非常符合潮流。现在请你想一想,这个变化会带来什么影响。看看代码你就会发现,根本不可能在打印报表的函数中复用(reuse)目前statement() 的任何行为。你惟一可以做的就是编写一个全新的htmlStatement() ,大量重复statement() 的行为。当然,现在做这个还不太费力,你可以把statement() 复制一份然后按需要修改就是。
-
但如果计费标准发生变化,又会发生什么事?你必须同时修改statement() 和htmlstatement() ,并确保两处修改的一致性。当你后续还要再修改时,剪贴(copy-paste)问题就浮现出来了。如果你编写的是一个永不需要修改的程序,那么剪剪贴贴就还好,但如果程序要保存很长时间,而且可能需要修改,剪贴行为就会造成潜在的威胁。
-
现在,第二个变化来了:用户希望改变影片分类规则,但是还没有决定怎么改。他 们设想了几种方案,这些方案都会影响顾客消费和常客积点的计算方式。作为一个经验丰富的开发者,你可以肯定:不论用户提出什么方案,你惟一能够获得的保证就是他们一定会在六个月之内再次修改它。
-
为了应付分类规则和计费规则的变化,程序必须对statement() 作出修改。但如果我们把statement() 内的代码拷贝到用以打印报表的函数中,我们就必须确保将来的任何修改在两个地方保持一致。随着各种规则变得愈来愈复杂,适当的修改点愈来愈难找,不犯错的机会也愈来愈少。
-
你的态度也许倾向于「尽量少修改程序」:不管怎么说,它还运行得很好。你心里头牢牢记着那句古老的工程学格言:「如果它没坏,就别动它」。这个程序也许还没坏掉,但它带来了伤害。它让你的生活比较难过,因为你发现很难完成客户所需的修改。这时候就该重构技术粉墨登场了。
本文章来自:http://blog.mkfree.com/posts/15