### Replace Nested Conditional with Guard Clauses(以衛語句取代嵌套條件式)
函數中的條件邏輯(conditional logic)使人難以看清正常的執行路徑。
使用衛語句(guard clauses)表現所有特殊情況。
~~~
double getPayAmount() {
double result;
if (_isDead) result = deadAmount();
else {
if (_isSeparated) result = separatedAmount();
else {
if (_isRetired) result = retiredAmount();
else result = normalPayAmount();
};
}
return result;
};
~~~
=>
~~~
double getPayAmount() {
if (_isDead) return deadAmount();
if (_isSeparated) return separatedAmount();
if (_isRetired) return retiredAmount();
return normalPayAmount();
};
~~~
**動機(Motivation)**
根據我的經驗,條件式通常有兩種呈現形式。第一種形式是:所有分支都屬于正常行為。第二種形式則是:條件式提供的答案中只有一種是正常行為,其他都是不常見的情況。
這兩類條件式有不同的用途,這一點應該通過代碼表現出來。如果兩條分支都是正常行為,就應該使用形如「if…then…」的條件式;如果某個條件極其罕見,就應該單獨檢查該條件,并在該條件為真時立刻從函數中返回。這樣的單獨檢查常常被稱為「衛語句(guard clauses)」[Beck]。
Replace Nested Conditional with Guard Clauses 的精髓就是:給某一條分支以特別的重視。如果使用if-then-else 結構,你對if 分支和else 分支的重視是同等的。 這樣的代碼結構傳遞給閱讀者的消息就是:各個分支有同樣的重要性。衛語句(guard clauses)就不同了,它告訴閱讀者:『這種情況很罕見,如果它真的發生了,請做 一些必要的整理工作,然后退出。』
「每個函數只能有一個入口和一個出口」的觀念,根深蒂固于某些程序員的腦海里。 我發現,當我處理他們編寫的代碼時,我經常需要使用Replace Nested Conditional with Guard Clauses。現今的編程語言都會強制保證每個函數只有一個入口, 至于「單一出口」規則,其實不是那么有用。在我看來,保持代碼清晰才是最關鍵的:如果「單一出口」能使這個函數更清楚易讀,那么就使用單一出口;否則就不必這么做。
**作法(Mechanics)**
- 對于每個檢查,放進一個衛語句(guard clauses)。
- 衛語句要不就從函數中返回,要不就拋出一個異常(exception)。
- 每次將「條件檢查」替換成「衛語句」后,編譯并測試。
- 如果所有衛語句都導致相同結果,請使用Consolidate Conditional Expressions。
**范例:(Example)**
想像一個薪資系統,其中以特殊規則處理死亡員工、駐外員工、退休員工的薪資。這些情況不常有,但的確偶而會出現。
假設我在這個系統中看到下列代碼:
~~~
double getPayAmount() {
double result;
if (_isDead) result = deadAmount();
else {
if (_isSeparated) result = separatedAmount();
else {
if (_isRetired) result = retiredAmount();
else result = normalPayAmount();
};
}
return result;
};
~~~
在這段代碼中,非正常情況的檢查掩蓋了正常情況的檢查,所以我應該使用『衛語句」來取代這些檢查,以提高程序清晰度。我可以逐一引入衛語句。讓我們從最上面的條件檢查動作開始:
~~~
double getPayAmount() {
double result;
if (_isDead) return deadAmount();
if (_isSeparated) result = separatedAmount();
else {
if (_isRetired) result = retiredAmount();
else result = normalPayAmount();
};
return result;
};
~~~
然后,繼續下去,仍然一次替換一個檢查動作:
~~~
double getPayAmount() {
double result;
if (_isDead) return deadAmount();
if (_isSeparated) return separatedAmount();
if (_isRetired) result = retiredAmount();
else result = normalPayAmount();
return result;
};
~~~
然后是最后一個:
~~~
double getPayAmount() {
double result;
if (_isDead) return deadAmount();
if (_isSeparated) return separatedAmount();
if (_isRetired) return retiredAmount();
result = normalPayAmount();
return result;
};
~~~
此時,result 變量已經沒有價值了,所以我把它刪掉:
~~~
double getPayAmount() {
if (_isDead) return deadAmount();
if (_isSeparated) return separatedAmount();
if (_isRetired) return retiredAmount();
return normalPayAmount();
};
~~~
嵌套(nested)條件代碼往往由那些深信「每個函數只能有一個出口」的程序員寫出。我發現那條規則(函數只能有一個出口)實在有點太簡單化了。如果對函數剩余部分不再有興趣,當然應該立刻退出。引導閱讀者去看一個沒有用的else 區段,只會妨礙他們的理解。
**范例:將條件逆反(Reversing the Conditions)**
審閱本書初稿時,Joshua Kerievsky 指出:你常常可以將條件表達式逆反,從而實現Replace Nested Conditional with Guard Clauses。為了拯救我可憐的想像力,他還好心幫我想了個例子:
~~~
public double getAdjustedCapital() {
double result = 0.0;
if (_capital > 0.0) {
if (_intRate > 0.0 && _duration > 0.0) {
result = (_income / _duration) * ADJ_FACTOR;
}
}
return result;
}
~~~
同樣地,我逐一進行替換。不過這次在插入衛語句(guard clauses)時,我需要將相應的條件逆反過來:
~~~
public double getAdjustedCapital() {
double result = 0.0;
if (_capital <= 0.0) return result;
if (_intRate > 0.0 && _duration > 0.0) {
result = (_income / _duration) * ADJ_FACTOR;
}
return result;
}
~~~
下一個條件稍微復雜一點,所以我分兩步進行逆反。首先加入一個"logical-NOT"操作:
~~~
public double getAdjustedCapital() {
double result = 0.0;
if (_capital <= 0.0) return result;
if (!(_intRate > 0.0 && _duration > 0.0)) return result;
result = (_income / _duration) * ADJ_FACTOR;
return result;
}
~~~
但是在這樣的條件式中留下一個"logical-NOT",會把我的腦袋擰成一團亂麻,所以我把它簡化成下面這樣:
~~~
public double getAdjustedCapital() {
double result = 0.0;
if (_capital <= 0.0) return result;
if (_intRate <= 0.0 || _duration <= 0.0) return result;
result = (_income / _duration) * ADJ_FACTOR;
return result;
}
~~~
這時候我比較喜歡在衛語句(guard clause)內返回一個明確值,因為這樣我可以一 目了然地看到衛語句返回的失敗結果。此外,這種時候我也會考慮使用Replace Magic Number with Symbolic Constant 。
~~~
public double getAdjustedCapital() {
double result = 0.0;
if (_capital <= 0.0) return 0.0;
if (_intRate <= 0.0 || _duration <= 0.0) return 0.0;
result = (_income / _duration) * ADJ_FACTOR;
return result;
}
~~~
完成替換之后,我同樣可以將臨時變量移除:
~~~
public double getAdjustedCapital() {
if (_capital <= 0.0) return 0.0;
if (_intRate <= 0.0 || _duration <= 0.0) return 0.0;
return (_income / _duration) * ADJ_FACTOR;
}
~~~
- 譯序 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 )
- 小結
- 章節十五 集成
- 參考書目