書接上回，我們繼續聊如何用重構指導Clean Code。

在Clean Code的3.4節中有這樣一段代碼（代碼清單3-4）。（第3章主要講的是函數，而3.4節討論的是switch語句。）

public Money calculatePay(Employee e) throws InvalidEmployeeType {switch (e.type) {case COMMISSIONED:return calculateCommissionedPay(e);case HOURLY:return calculateHourlyPay(e);case SALARIED:return calculateSalariedPay(e);default:throw new InvalidEmployeeType(e.type);} }

Bob大叔細數了這段代碼的幾處問題：

太長，當出現新的Employee類型時，還會變得更長

明顯做了不止一件事

違反了單一權責原則，因為有好幾個修改它的理由

違反了開放閉合原則，因為每當添加新類型時，就必須修改之

最麻煩的是到處皆有類似結構的函數

其中1和4說的是一回事兒，每當新增加一種類型的Employee，就必須在這個switch里添加新的case。2和3說的是一回事兒，這個方法為三種類型的Employee計算費用，任何一種類型的計算邏輯發生變化，都要修改這個計算方法（或者對應的計算方法）。

對于第5點，Bob大叔的意思是說，calculatePay(Employee e)這個方法所在的類中還會有類似isPayDay(Employee e, Date date)或deliverPay(Employee e, Money pay)這樣的方法，由于Employee具有不同的類型（type），那么這些方法中肯定也會出現類似的switch語句。

講到這里還是非常清晰的，然而Bob大叔接下來又開始魔幻操作，直接給出了解決方案：

將switch語句埋到抽象工廠底下，不讓任何人看到。該工廠使用switch語句為Employee的派生物創建適當的實體，而不同的函數，如calculatePay、isPayday和deliverPay等，則藉由Employee接口多態地接受派遣。

哪里來的抽象工廠？Employee怎么就有了派生類？再一看代碼

public abstract class Employee {public abstract boolean isPayday();public abstract Money calculatePay();public abstract void deliverPay(Money pay); } ----------------- public interface EmployeeFactory { public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType; } ----------------- public class EmployeeFactoryImpl implements EmployeeFactory {public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {switch (r.type) {case COMMISSIONED:return new CommissionedEmployee(r) ;case HOURLY:return new HourlyEmployee(r);case SALARIED:return new SalariedEmploye(r);default:throw new InvalidEmployeeType(r.type);}} }

妙啊，6啊，Bob大叔簡直是神啊！

然而，面對同樣的問題代碼，我們能做出這樣的修改嗎？我們能構造出Employee的繼承體系嗎？能抽象出EmployeeFactory嗎？反正對我來說，僅看Clean Code是做不到的。Bob大叔的技炫得神乎其神，但無奈只有結果，沒有過程，讓初學者不明所以。所以，這個時候就要祭出神器《重構》了。

《重構》要求我們在重構代碼之前，先識別壞味道。然后針對你想去消除的那個壞味道，按照相應的重構手法，一步一步讓這個壞味道消失。我曾經在真實的遺留系統中演練過“壞味道驅動的重構“（SDR，Smell Driven Refactoring，這是我發明的一個詞兒），效果還是不錯的。

還是上面有問題的代碼，我們看看按照《重構》應該怎么重構：

public Money calculatePay(Employee e) throws InvalidEmployeeType {switch (e.type) {case COMMISSIONED:return calculateCommissionedPay(e);case HOURLY:return calculateHourlyPay(e);case SALARIED:return calculateSalariedPay(e);default:throw new InvalidEmployeeType(e.type);} }

這里的壞味道很多，最一目了然的可能就是”Switch Statements（Switch驚悚現身）“，當然還有Bob大叔指出的違反SRP和OCP，但在壞味道中，我們管它叫做”Divergent Change（發散式變化）“。然而要消除這兩個壞味道都不是那么容易，我只想從最簡單的開始。什么是最簡單的呢？

首先calculatePay方法有一個Employee類型的參數，除此之外，它沒有使用該方法所在類的任何成員。同理可以推斷該方法所使用的其他三個方法應該也只是使用Employee，不會使用該方法所在類的成員。這時，”Feature Envy（依戀情結）“的壞味道就顯現出來了。

有一種經典氣味是：函數對某個類的興趣高過對自己所處類的興趣。這種孺慕之情最通常的焦點便是數據。無數次經驗里，我們看到某個函數為了計算某個值，從另一個對象那兒調用幾乎半打的取值函數。

對于該方法，豈止是半打，簡直就是全部。老馬不但指出了問題，還給出了方案：

療法顯而易見：把這個函數移至另一個地點。你應該使用"Move Method（搬移函數）把它移到它該去的地方”

沒什么好說的，挪唄。將calculateCommisstionPay、calculateHourlyPay、calculateSalariedPay方法，以及它自己全部挪到Employee中（常用IDE都支持重構，這里不再贅述）：

public Money calculatePay() throws InvalidEmployeeType {switch (this.type) {case COMMISSIONED:return this.calculateCommissionedPay();case HOURLY:return this.calculateHourlyPay();case SALARIED:return this.calculateSalariedPay();default:throw new InvalidEmployeeType(this.type);} }

樣一來，該方法只使用Employee自己的數據，”依戀情結“的壞味道不見了。

是禍躲不過，Switch這個壞味道早晚得面對。

從本質上說，switch語句的問題在于重復。你常會發現同樣的switch語句散布于不同地點。如果要為它添加一個新的case子句，就必須找到所有switch語句并修改它們。

這也正是Bob大叔所說的”最麻煩的是到處皆有類似結構的函數“。好在老馬一如既往給出了解決方案：

面向對象中的多態概念可為此帶來優雅的解決辦法。

switch語句常常根據類型碼進行選擇，你要的是“與該類型碼相關的函數或類”，……使用Replace Type Code with Subclasses 或Replace Type Code with State/Strategy。一旦這樣完成繼承結構之后，你就可以運用Replace Conditional with Polymorphism了。

由于我們已經通過消除”依戀情結“將方法移動到了Employee中，所以接下來只需要從類型碼入手就好了。這里我們選擇使用Replace Type Code with Subclass（以子類取代類型碼）這個重構手法。打開《重構》相關章節一看，給出的例子簡直跟我們這里的一模一樣，兩位大師是商量好的吧？

abstract int getType(); abstract Money calculatePay();static Employee create(int type) {switch (type) {case COMMISSIONED:return new CommissionedEmployee();case HOURLY:return new HourlyEmployee();case SALARIED:return new SalariedEmployee();default:throw new InvalidEmployeeType(type);} }

怎么樣？是不是與Bob大叔的幻改異曲同工？（EmployeeRecord之類的屬于細枝末節，不再贅述。）

除此之外，老馬還給出了消除類型碼的其他方案（Replace Type Code with State/Strategy），以及徹底消除switch的辦法（Replace Conditional with Polymorphism）。

這樣細致入微的教導，是不是比直接告訴你答案要實用得多？

事實上對于上例這種有很多壞味道的代碼，你完全可以按個人喜好來選擇不同的重構順序，得到的結果可能千差萬別，也可能殊途同歸，但肯定都算是不錯的設計。

這就是代碼的魅力。

總結

以上是生活随笔為你收集整理的用重构指导Clean Code（二）：依恋情结和switch语句的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。