### Replace Conditional with Polymorphism(以多態取代條件式)
你手上有個條件式,它根據對象型別的不同而選擇不同的行為。
將這個條件式的每個分支放進一個subclass 內的覆寫函數中,然后將原始函數聲明為抽象函數(abstract method)。
~~~
double getSpeed() {
switch (_type) {
case EUROPEAN:
return getBaseSpeed();
case AFRICAN:
return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts;
case NORWEGIAN_BLUE:
return (_isNailed) ? 0 : getBaseSpeed(_voltage);
}
throw new RuntimeException ("Should be unreachable");
}
~~~

**動機(Motivation)**
在面向對象術語中,聽上去最高貴的詞非「多態」莫屬。多態(polymorphism)最根本的好處就是:如果你需要根據對象的不同型別而采取不同的行為,多態使你不必編寫明顯的條件式(explicit conditional )。
正因為有了多態,所以你會發現:「針對type code(型別碼)而寫的switch 語句」 以及「針對type string (型別名稱字符串)而寫的if-then-else 語句」在面向對象程序中很少出現。
多態(polymorphism)能夠給你帶來很多好處。如果同一組條件式在程序許多地點出現,那么使用多態的收益是最大的。使用條件式時,如果你想添加一種新型別,就必須查找并更新所有條件式。但如果改用多態,只需建立一個新的subclass ,并在其中提供適當的函數就行了。class 用戶不需要了解這個subclass ,這就大大降低了系統各部分之間的相依程度,使系統升級更加容易。
**作法(Mechanics)**
使用Replace Conditional with Polymorphism之前,你首先必須有一個繼承結構。你可能已經通過先前的重構得到了這一結構。如果還沒有,現在就需要建立它。
要建立繼承結構,你有兩種選擇: Replace Type Code with Subclasses 和 Replace Type Code with State/Strategy。前一種作法比較簡單,因此你應該盡可能使用它。但如果你需要在對象創建好之后修改type code;就不能使用subclassing 作法,只能使用State/Strategy 模式。此,如果由于其他原因你要重構的class 已經有了subclass ,那么也得使用State/Strategy 。記住,如果若干switch 語句針對的是同一個type code;你只需針對這個type code 建立一個繼承結構就行 了。
現在,可以向條件式開戰了。你的目標可能是switch(case)語句,也可能是if 語句。
- 如果要處理的條件式是一個更大函數中的一部分,首先對條件式進行分析,然后使用Extract Method 將它提煉到一個獨立函數去。
- 如果有必要,使用Move Method 將條件式放置到繼承結構的頂端。
- 任選一個subclass ,在其中建立一個函數,使之覆寫superclass 中容納條件式的那個函數。將「與subclass 相關的條件式分支」拷貝到新建函數中,并對它進行適當調整。
- 為了順利進行這一步驟,你可能需要將superclass 中的某些private 值域聲明為protected 。
- 編譯,測試。
- 在superclass 中刪掉條件式內被拷貝出去的分支。
- 編譯,測試。
- 針對條件式的每個分支,重復上述過程,直到所有分支都被移到subclass 內的函數為止。
- 將superclass 之中容納條件式的函數聲明為抽象函數(abstract method)。
**范例:(Example)**
請允許我繼續使用「員工與薪資」這個簡單而又乏味的例子。我的classes是從Replace Type Code with State/Strategy 那個例子中拿來的,因此示意圖就如圖9.1所示(如果想知道這個圖是怎么得到的,請看第8章范例)。

圖9.1 繼承機構
~~~
class Employee...
int payAmount() {
switch (getType()) {
case EmployeeType.ENGINEER:
return _monthlySalary;
case EmployeeType.SALESMAN:
return _monthlySalary + _commission;
case EmployeeType.MANAGER:
return _monthlySalary + _bonus;
default:
throw new RuntimeException("Incorrect Employee");
}
}
int getType() {
return _type.getTypeCode();
}
private EmployeeType _type;
abstract class EmployeeType...
abstract int getTypeCode();
class Engineer extends EmployeeType...
int getTypeCode() {
return Employee.ENGINEER;
}
... and other subclasses
~~~
switch 語句已經被很好地提煉出來,因此我不必費勁再做一遍。不過我需要將它移至EmployeeType class,因為EmployeeType 才是被subclassing 的class 。
~~~
class EmployeeType...
int payAmount(Employee emp) {
switch (getTypeCode()) {
case ENGINEER:
return emp.getMonthlySalary();
case SALESMAN:
return emp.getMonthlySalary() + emp.getCommission();
case MANAGER:
return emp.getMonthlySalary() + emp.getBonus();
default:
throw new RuntimeException("Incorrect Employee");
}
}
~~~
由于我需要EmployeeType class 的數據,所以我需要將Employee 對象作為參數傳遞給payAmount()。這些數據中的一部分也許可以移到EmployeeType class 來,但那是另一項重構需要關心的問題了。
調整代碼,使之通過編譯,然后我修改Employee 中的payAmount() 函數,令它委托(delegate,轉調用)EmployeeType :
~~~
class Employee...
int payAmount() {
return _type.payAmount(this);
}
~~~
現在,我可以處理switch 語句了。這個過程有點像淘氣小男孩折磨一只昆蟲——每次掰掉它一條腿 [6]。首先我把switch 語句中的"Engineer"這一分支拷貝到Engineer class:
~~~
class Engineer...
int payAmount(Employee emp) {
return emp.getMonthlySalary();
}
~~~
[6]譯注:「腿」和條件式「分支」的英文都是"leg"。作者幽默地說「掰掉一條腿」, 意思就是「去掉一個分支」。
這個新函數覆寫了superclass 中的switch 語句之內那個專門處理"Engineer"的分支。我是個徧執狂,有時我會故意在case 子句中放一個陷阱,檢查Engineer class 是否正常工作(是否被調用):
~~~
class EmployeeType...
int payAmount(Employee emp) {
switch (getTypeCode()) {
case ENGINEER:
throw new RuntimeException ("Should be being overridden");
case SALESMAN:
return emp.getMonthlySalary() + emp.getCommission();
case MANAGER:
return emp.getMonthlySalary() + emp.getBonus();
default:
throw new RuntimeException("Incorrect Employee");
}
}
~~~
接下來,我重復上述過程,直到所有分支都被去除為止:
~~~
class Salesman...
int payAmount(Employee emp) {
return emp.getMonthlySalary() + emp.getCommission();
}
class Manager...
int payAmount(Employee emp) {
return emp.getMonthlySalary() + emp.getBonus();
}
~~~
然后,將superclass 的payAmount() 函數聲明為抽象函數:
~~~
class EmployeeType...
abstract int payAmount(Employee emp);
~~~
- 譯序 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 )
- 小結
- 章節十五 集成
- 參考書目