java 代码重构-第一章(起点)

 

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