### 运用多态（Polymorphism）取代与价格相关的条件逻辑
这个问题的第一部分是switch 语句。在另一个对象的属性（attribute）基础上运用switch 语句，并不是什么好主意。如果不得不使用，也应该在对象自己的数据上使用，而不是在别人的数据上使用。
~~~
class Rental...
double getCharge() {
double result = 0;
switch (getMovie().getPriceCode()) {
case Movie.REGULAR:
result += 2;
if (getDaysRented() > 2)
result += (getDaysRented() - 2) * 1.5;
break;
case Movie.NEW_RELEASE:
result += getDaysRented() * 3;
break;
case Movie.CHILDRENS:
result += 1.5;
if (getDaysRented() > 3)
result += (getDaysRented() - 3) * 1.5;
break;
}
return result;
}
~~~
这暗示getCharge() 应该移到Movie class 里头去：
~~~
class Movie...
double getCharge(int daysRented) {
double result = 0;
switch (getPriceCode()) {
case Movie.REGULAR:
result += 2;
if (daysRented > 2)
result += (daysRented - 2) * 1.5;
break;
case Movie.NEW_RELEASE:
result += daysRented * 3;
break;
case Movie.CHILDRENS:
result += 1.5;
if (daysRented > 3)
result += (daysRented - 3) * 1.5;
break;
}
return result;
}
~~~
为了让它得以运作，我必须把「租期长度」作为参数传递进去。当然，「租期长度」来自收Rental 对象。计算费用时需要两份数据：「租期长度」和「影片类型」。为什么我选择「将租期长度传给Movie 对象」而不是「将影片类型传给Rental 对象」呢？因为本系统可能发生的变化是加入新影片类型，这种变化带有不稳定倾向。如果影片类型有所变化，我希望掀起最小的链滴，所以我选择在Movie 对象内计算费用。
我把上述计费方法放进Movie class 里头，然后修改Rental 的getCharge()，让它使用这个新函数（图1.12和图1.13）：
图1.12 本节所讨论的两个函数被移到Movie class 内之前系统的class diagram
图1.13 本节所讨论的两个函数被移到Movie class 内之后系统的class diagram
~~~
class Rental...
double getCharge() {
return _movie.getCharge(_daysRented);
}
~~~
搬移getCharge() 之后，我以相同手法处理常客积点计算。这样我就把根据影片类型而变化的所有东西，都放到了影片类型所属的class 中。
以下是重构前的代码：
~~~
class Rental...
int getFrequentRenterPoints() {
if ((getMovie().getPriceCode() == Movie.NEW_RELEASE) && getDaysRented() > 1)
return 2;
else
return 1;
}
~~~
重构如下：
~~~
Class rental...
int getFrequentRenterPoints() {
return _movie.getFrequentRenterPoints(_daysRented);
}
class movie...
int getFrequentRenterPoints(int daysRented) {
if ((getPriceCode() == Movie.NEW_RELEASE) && daysRented > 1)
return 2;
else
return 1;
}
~~~
终于……我们来到继承（Inheritance）
我们有数种影片类型，它们以不同的方式回答相同的问题。这听起来很像subclasses 的工作。我们可以建立Movie 的三个subclasses ，每个都有自己的计费法（图1.14）。
图1.14 以继承机制表现不同的影片类型
这么一来我就可以运用多态（polymorphism）来取代switch 语句了。很遗憾的是这里有个小问题，不能这么干。一部影片可以在生命周期内修改自己的分类，一个对象却不能在生命周期内修改自己所属的class。不过还是有一个解决方法：State pattern（模式）[Gang of Four]。运用它之后，我们的classes 看起来像图1.15。
图1.15 运用State pattern（模式）表现不同的影片
加入这一层间接性，我们就可以在Price 对象内进行subclassing 动作（译注：一如图1.15），于是便可在任何必要时刻修改价格。
如果你很熟悉Gang of Four 所列的各种模式（patterns），你可能会问：『这是一个State 还是一个Strategy？』答案取决于Price class 究竟代表计费方式（此时我喜欢把它叫做Pricer 或PricingStrategy），或是代表影片的某个状态（state，例如「Star Trek X 是一部新片」）。在这个阶段，对于模式（和其名称）的选择反映出你对结构的想法。此刻我把它视为影片的某种状态（state）。如果未来我觉得Strategy 能更好地说明我的意图，我会再重构它，修改名字，以形成Strategy 。
为了引入State 模式，我使用三个重构准则。首先运用Replace Type Code with State/Strategy，将「与型别相依的行为」（type code behavior ）搬移至State 模式内。然后运用Move Method 将switch 语句移到Price class 里头。最后运用Replace Conditional with Polymorphism去掉switch 语句。
首先我要使用Replace Type Code with State/Strategy。第一步骤是针对「与 型别相依的行为」使用Self Encapsulate Field，确保任何时候都通过getting 和setting 两个函数来运用这些行为。由于多数代码来自其他classes，所以多数函数都己经使用getting 函数。但构造函数（constructor ）仍然直接访问价格代号（译注：程序中的_priceCode）：
~~~
class Movie...
public Movie(String name, int priceCode) {
_name = name;
_priceCode = priceCode;
}
~~~
我可以用一个setting 函数来代替：
~~~
class Movie
public Movie(String name, int priceCode) {
_name = name;
setPriceCode(priceCode); //译注：这就是一个set method
}
~~~
然后编译并测试，确保没有破坏任何东西。现在我加入新class，并在Price 对象中提供「与型别相依的行为」。为了实现这一点，我在Price 内加入一个抽象函数（abstract method ），并在其所有subclasses 中加上对应的具体函数（concrete method）：
~~~
abstract class Price {
abstract int getPriceCode(); //取得价格代号
}
class ChildrensPrice extends Price {
int getPriceCode() {
return Movie.CHILDRENS;
}
}
class NewReleasePrice extends Price {
int getPriceCode() {
return Movie.NEW_RELEASE;
}
}
class RegularPrice extends Price {
int getPriceCode() {
return Movie.REGULAR;
}
}
~~~
现在我可以编译这些新classes了。
现在，我需要修改Movie class 内的「价格代号」访问函数（get/set函数，如下），让它们使用新class。
下面是重构前的样子：
~~~
public int getPriceCode() {
return _priceCode;
}
public setPriceCode (int arg) {
_priceCode = arg;
}
private int _priceCode;
~~~
这意味我必须在Movie class 内保存一个Price 对象，而不再是保存一个_priceCode 变量。此外我还需要修改访问函数（译注：即get/set函数）：
~~~
class Movie...
public int getPriceCode() { //取得价格代号
return _price.getPriceCode();
}
public void setPriceCode(int arg) { //设定价格代号
switch (arg) {
case REGULAR:
_price = new RegularPrice();
break;
case CHILDRENS:
_price = new ChildrensPrice();
break;
case NEW_RELEASE:
_price = new NewReleasePrice();
break;
default:
throw new IllegalArgumentException("Incorrect Price Code");
}
}
private Price _price;
~~~
现在我可以重新编译并测试，那些比较复杂的函数根本不知道世界巳经变了个样儿。
现在我要对getCharge() 实施Move Method。
下面是重构前的代码：
~~~
class Movie...
double getCharge(int daysRented) {
double result = 0;
switch (getPriceCode()) {
case Movie.REGULAR:
result += 2;
if (daysRented > 2)
result += (daysRented - 2) * 1.5;
break;
case Movie.NEW_RELEASE:
result += daysRented * 3;
break;
case Movie.CHILDRENS:
result += 1.5;
if (daysRented > 3)
result += (daysRented - 3) * 1.5;
break;
}
return result;
}
~~~
搬移动作很简单。下面是重构后的代码。
~~~
class Movie...
double getCharge(int daysRented) {
return _price.getCharge(daysRented);
}
class Price...
double getCharge(int daysRented) {
double result = 0;
switch (getPriceCode()) {
case Movie.REGULAR:
result += 2;
if (daysRented > 2)
result += (daysRented - 2) * 1.5;
break;
case Movie.NEW_RELEASE:
result += daysRented * 3;
break;
case Movie.CHILDRENS:
result += 1.5;
if (daysRented > 3)
result += (daysRented - 3) * 1.5;
break;
}
return result;
}
~~~
搬移之后，我就可以开始运用Replace Conditional with Polymorphism了。下面是重构前的代码。
~~~
class Price...
double getCharge(int daysRented) {
double result = 0;
switch (getPriceCode()) {
case Movie.REGULAR:
result += 2;
if (daysRented > 2)
result += (daysRented - 2) * 1.5;
break;
case Movie.NEW_RELEASE:
result += daysRented * 3;
break;
case Movie.CHILDRENS:
result += 1.5;
if (daysRented > 3)
result += (daysRented - 3) * 1.5;
break;
}
return result;
}
~~~
我的作法是一次取出一个case 分支，在相应的class内建立一个覆写函数（overriding method）。先从RegularPrice 开始：
~~~
class RegularPrice...
double getCharge(int daysRented){
double result = 2;
if (daysRented > 2)
result += (daysRented - 2) * 1.5;
return result;
}
~~~
这个函数覆写（overrides）了父类中的case 语句，而我暂时还把后者留在原处不动。现在编译并测试，然后取出下一个case 分支，再编译并测试。（为了保证被执行的的确是subclass 代码，我喜欢故意丢一个错误进去，然后让它运行，让测试失败。噢，我是不是有点太偏执了？）
~~~
class ChildrensPrice
double getCharge(int daysRented){
double result = 1.5;
if (daysRented > 3)
result += (daysRented - 3) * 1.5;
return result;
}
class NewReleasePrice...
double getCharge(int daysRented){
return daysRented * 3;
}
~~~
处理完所有case 分支之后，我就把Price.getCharge() 声明为abstract。
~~~
class Price...
abstract double getCharge(int daysRented);
~~~
现在我可以运用同样手法处理getFrequentRenterPoints()。重构前的样子如下（译注：其中有「与型别相依的行为」，也就是「判断是否为新片」那个动作）。
~~~
class Rental...
int getFrequentRenterPoints(int daysRented) {
if ((getPriceCode() == Movie.NEW_RELEASE) && daysRented > 1)
return 2;
else
return 1;
}
~~~
首先我把这个函数移到Price class 里头。
~~~
Class Movie...
int getFrequentRenterPoints(int daysRented) {
return _price.getFrequentRenterPoints(daysRented);
}
Class Price...
int getFrequentRenterPoints(int daysRented) {
if ((getPriceCode() == Movie.NEW_RELEASE) && daysRented > 1)
return 2;
else
return 1;
}
~~~
但是这一次我不把superclass 函数声明为abstract。我只是为「新片类型」产生一个覆写函数（overriding method ），并在superclass 内留下一个已定义的函数，使它成为一种缺省行为。
~~~
//译注：在新片中产生一个覆写函数（overriding method ）
Class NewReleasePrice
int getFrequentRenterPoints(int daysRented) {
return (daysRented > 1) ? 2: 1;
}
//译注：在superclass 内保留它，使它成为一种缺省行。
Class Price...
int getFrequentRenterPoints(int daysRented){
return 1;
}
~~~
引入State 模式花了我不少力气，值得吗？这么做的收获是：如果我要修改任何与价格有关的行为，或是添加新的定价标准，或是加入其他取决于价格的行为，程序的修改会容易得多。这个程序的其余部分并不知道我运用了State 模式。对于我目前拥有的这么几个小量行为来说，任何功能或特性上的修改也许都称不上什么困难，但如果在一个更复杂的系统中，有十多个与价格相关的函数，程序的修改难易度就会有很大的区别。以上所有修改都是小步骤进行，进度似乎太过缓慢，但是没有任何一次我需要打开调试器（debugger），所以整个过程实际上很快就过去了。我书写本章所用的时间，远比修改那些代码的时间多太多了。
现在我已经完成了第二个重要的重构行为。从此，修改「影片分类结构」，或是改变「费用计算规则」、改变常客积点计算规则，都容易多了。图1.16和图1.17描述State 模式对于价格信息所起的作用。
图1.16 运用State pattern （模式）当时的Interaction diagram
图1.17 加入State pattern （模式）之后的class diagram
- 译序 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 ）
- 小结
- 章节十五 集成
- 参考书目