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() 内的代码拷贝到用以打印报表的函数中,我们就必须确保将来的任何修改在两个地方保持一致。随着各种规则变得愈来愈复杂,适当的修改点愈来愈难找,不犯错的机会也愈来愈少。
-
你的态度也许倾向于「尽量少修改程序」:不管怎么说,它还运行得很好。你心里头牢牢记着那句古老的工程学格言:「如果它没坏,就别动它」。这个程序也许还没坏掉,但它带来了伤害。它让你的生活比较难过,因为你发现很难完成客户所需的修改。这时候就该重构技术粉墨登场了。