Ada-苏婉妤

重构改善既有代码的设计 java_重构改善既有代码的设计：代码的坏

以下内容来自<>

一、什么是重构

所谓重构(Refactoring)是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。从本质上说，重构就是在代码写好之后改进它的设计。

二、什么样的代码需要重构

哪些代码需要重构呢？<>中列出了一个“坏味道条款”，当代码中出现了这些坏味道时，应该考虑重构。

代码的坏味道

1.用多态代替价格条件逻辑代码

经过前一阶段的重构，我们注意到switch语句：在Rental类中使用了Movie类的属性，这不是什么好主意，如果不得不使用，我们应该尽量在自己对象上使用自己的数据，而不应该过多的使用别人的数据，如：

这暗示我们应该先把getCharge()移动到Movie中：

publicclassMovie ...publicdoublegetCharge(intdaysRented) {doubleresult=0;switch(getPriceCode()) {//各种影片的价格不同caseMovie.REGULAR:

result+=2;if(daysRented>2)

result+=(daysRented-2)*1.5;break;caseMovie.NEW_RELEASE:

result+=daysRented*3;break;caseMovie.CHILDRENS:

result+=1.5;if(daysRented>3)

result+=(daysRented-3)*1.5;break;

}returnresult;

}

为了能够让程序正常运行，我们需要将租期长度作为参数传递进去。然而，租期长度又来自于Rental类，这里你就可能产生疑问了。既然switch语句会影响两个类中的数据，我们为什么要把getCharge()从Rental(此方法在Rental中表示：将影片类型传递到Rental对象)类中移到Movie(将租期长度传递到Movie对象)类中呢？因为本系统可能发生的变化是影片类型的改变，这种变化是不稳定的。我希望引起的连锁反应是最小的，所以选择在Movie中计算费用。相应的，应该改变Rental类：

publicclassRental ...publicdoublegetCharge() {returnmovie.getCharge(daysRented);

}

移动了getCharge()方法后，我以同样的手法处理点数(积分)的计算，以保证把将会因影片类型改变而改变的代码都放入Movie类中。Rental类就由：

publicclassRental ...publicintgetFrequentRenterPoints() {if((getMovie().getPriceCode()==Movie.NEW_RELEASE)&&getDaysRented()>1)return2;elsereturn1;

}

变成：

publicclassRental ...publicintgetFrequentRenterPoints() {returnmovie.getFrequentRenterPoints(daysRented);

}

相应的Movie类中新增加一方法：

publicclassMovie...publicintgetFrequentRenterPoints(intdaysRented) {if(getPriceCode()==Movie.NEW_RELEASE&&daysRented>1)return2;elsereturn1;

}

2.终于说到继承了

我们有不同种类型的影片，它们以不同的类型回答相同的问题(影片类型的不同，都是为了计算出租赁的费用)。所以，我们想到了可以建立3个子类，每个子类都有自己的计费方式，它们计算各自的费用，它们的关系如下(以继承机制表现不同影片)：

这样，我们就可以用多态取代switch语句了。但是遗憾的是，我们不能这么干，因为一部影片可以在自己的生命周期内修改自己的类型，一个对象却不能在生命周期类修改自己所属的类。但是，我们仍有解决的办法，那就是运用State模式(或译：状态模式)，运用它以后，我们的类关系应该如下(运动State模式表现不同的影片)：

这里增加了一个中间层，就可以在Price对象进行继承动作了，我们可以按照我们的需求随时改变Price(价格)。

如果你很熟悉设计模式，你可能会问：这是一个State还是一个strategy？答案取决于Price类究竟代表计费方式还是代表影片的某个状态。对于模式的选择反映出你对结构的想法，这里把它视为影片的某种状态。如果未来你觉得strategy能更好的说明你的意图，你可以再改造它以形成strategy。

接下来，我将运用3个重构准则。首先运用了Replace Type Code with State/strategy，将与影片类型相互依赖的行为(Type Code bahavior)移动到State模式内。然后运用Move Method将switch语句移到了Price类中，最后运用Replace Conditional with Polymorphism去掉switch语句。

首先我使用Replace Type Code with State/strategy。第一步将与类型相依赖的属性使用Self Encapsulate Field以确保任何时候都可以通过get和set方法获得这些属性。这样做是因为其它类中的很多代码都已经使用了这些属性，大多数方法也通过get方法来获取这些属性。当然，构造方法仍然可以直接使用属性值。

publicclassMovie ...privateString title;//片名privateintpriceCode;//价格代号//getter and setter}

构造方法中我们可以用setter代替，如：

publicclassMovie ...privateString title;//片名privateintpriceCode;//价格代号//getter and setterpublicMovie(String title,intpriceCode) {this.title=title;

setPriceCode(priceCode);

}

现在我加入新的类，在Price 类中提供抽象方法getPriceCode(与类型相依赖的行为)，子类中来实现这个抽象方法：

publicabstractclassPrice {abstractintgetPriceCode();

}publicclassChildrensPriceextendsPrice {

@OverrideintgetPriceCode() {returnMovie.CHILDRENS;

}

}publicclassNewReleasePriceextendsPrice {

@OverrideintgetPriceCode() {returnMovie.NEW_RELEASE;

}

}publicclassRegularPriceextendsPrice {

@OverrideintgetPriceCode() {returnMovie.REGULAR;

}

先在我要修改Movie的访问方法(get和set方法)，下面是重构前的样子：

privateintpriceCode;//价格代号publicintgetPriceCode() {returnpriceCode;

}publicvoidsetPriceCode(intpriceCode) {this.priceCode=priceCode;

}

这意味着，我必须在Movie类中保存一个Price对象而不再是一个priceCode变量，此外我还要修改访问方法：

publicclassMovie ...privatePrice price;publicintgetPriceCode() {returnpriceCode;

}publicvoidsetPriceCode(intarg) {switch(arg) {//各种影片的价格不同caseREGULAR:

price=newRegularPrice();break;caseNEW_RELEASE:

price=newNewReleasePrice();break;caseMovie.CHILDRENS:

price=newChildrensPrice();break;default:thrownewIllegalArgumentException("Incorrect Price Code");

}

第二步，我将对getCharge()运用Move Method，重构之前如下：

publicclassMovie ...publicdoublegetCharge(intdaysRented) {doubleresult=0;switch(getPriceCode()) {//各种影片的价格不同caseMovie.REGULAR:

result+=2;if(daysRented>2)

result+=(daysRented-2)*1.5;break;caseMovie.NEW_RELEASE:

result+=daysRented*3;break;caseMovie.CHILDRENS:

result+=1.5;if(daysRented>3)

result+=(daysRented-3)*1.5;break;

}returnresult;

}

重构之后：

publicclassMovie ...publicdoublegetCharge(intdaysRented) {returnprice.getCharge(daysRented);

}publicabstractclassPrice ...publicdoublegetCharge(intdaysRented) {doubleresult=0;switch(getPriceCode()) {//各种影片的价格不同caseMovie.REGULAR:

result+=2;if(daysRented>2)

result+=(daysRented-2)*1.5;break;caseMovie.NEW_RELEASE:

result+=daysRented*3;break;caseMovie.CHILDRENS:

result+=1.5;if(daysRented>3)

result+=(daysRented-3)*1.5;break;

}returnresult;

}

第3步，我将运用Replace Conditional with Polymorphism，将switch的每一个分支用于一个子类的覆写方法，重构后如下：

publicabstractclassPrice {abstractdoublegetCharge(intdaysRented);

}publicclassRegularPriceextendsPrice {publicdoublegetCharge(intdaysRented) {doubleresult=2;if(daysRented>2)

result+=(daysRented-2)*1.5;returnresult;

}

}publicclassNewReleasePriceextendsPrice {

@OverridepublicdoublegetCharge(intdaysRented) {returndaysRented*3;

}

}publicclassChildrensPriceextendsPrice {

@OverridepublicdoublegetCharge(intdaysRented) {doubleresult=1.5;if(daysRented>3)

result+=(daysRented-3)*1.5;returnresult;

}

最后，在对象点数(积分)的计算采用同样的方法重构，这里不再累赘叙述。这里需要注意的是普通片和儿童片的积分点数是1，新片的积分点数是2，重构的方法看下面的UML图就容易理解了：

引入State模式花费了我们不少功夫，这样做是否值得呢？如果我要修改与任何与价格有关的行为，增加一个新的价格标准，或者其它有关价格的行为，我都将很容易的对系统进行修改，而这个程序的其它部分并不知道我运用了State模式。由于目前程序中的行为太少，所以我们修改起来很容易，当在一个大的系统中，比如与价格相关的行为有十多个，修改的难度与这个相比将会有很大区别。

3.结语

这是一个简单的实例，我希望它能够让你对重构有一点感觉。实例中我使用了几个重构准则：Extract Method，Move Method和Replace Conditional with Polymorpbism。所有这些重构行为的目的都是为了是责任分配更合理，代码维护更容易。它将与结构化的编程方式有很大区别，尽管很多人习惯后者。不过只要你一习惯重构后的风格，你就很难在回到过去了，因为结构化的编程风格已经不能满足你的需求了。

这个实例给你上的最重要一课：重构的节奏，测试，小修改，测试，小修改，测试，小修改…这是这样的节奏让重构既快速又安全。如果你能跟上这个节奏，你现在应该对重构有一个基本了解了，后面我们将了解一点背景，原理和理论，当然只是一点点。

坏味道

特征

情况及处理方式

目标

重复代码

1.重复的表达式2.不同算法做相同的事3.类似代码

同一个类的两个函数有相同表达式

重复代码提取为方法

相同表达式只在一个类的一个方法出现，供其他方法调用

兄弟类含有相同表达式

重复代码提取为方法提升方法到父类

不相干类含有相同代码

提取为独立类供调用

过长函数

1.代码前面有注释2.条件表达式3.循环

提取方法

每个方法只做一件事，方法要定义完善、命名准确

过大的类

1.一个类中有太多实例变量2.一个类中有太多代码

部分字段之间相关性高

重构 改善既有代码的设计 java_重构 改善既有代码的设计：代码的坏

你可能感兴趣的:(重构,改善既有代码的设计,java)

重构改善既有代码的设计 java_重构改善既有代码的设计：代码的坏