本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。

筆者常常看到許多分支發生在枚舉或其他離散值上，當某些開發人員被要求不要使用if-then-else時，甚至會感到惱火。if-else和switch當然可以生成簡潔的代碼，你的軟件不應該由最少的行組成，也不必犧牲可讀性、可維護性或靈活性。

[[343987]]

在if-then-else語句中使用枚舉的后果是什么呢?基于離散值的分支會使軟件難以更改。每個新功能都要求跟蹤分支發生的位置，并相應地修改現有代碼。

這絕對不是我們想要的方式。這或許是使代碼正常工作的第一步，但隨著你不斷改進代碼，switch和if-then-else肯定早已不復存在。

我必須要說，使用if-else和switch進行分支的傳統方法已過時。它不可靠、不靈活。傳統方法中沒有面向對象的內容。但是它仍在蓬勃發展，因為學生們被迫認為它是正確的，甚至是最佳實踐。代碼是有效的，但你可以做得更好。

設想一下這個問題。假設出于某種原因，必須用一種方法來更新用戶。為了簡單起見，用戶只出于兩種理由需要在系統中被更新。

最初的一組要求

你可以在以下代碼段中實現這兩種簡單的情況。花一點時間閱讀這段設計欠佳的代碼吧，許多高級開發人員都把此當作噩夢，它甚至被認為是引發“十年怕井繩”的那條蛇。

是的，我看到過這樣瘋狂的野生代碼。這是一個非常幼稚的操作，它假定用戶永遠沒有那么多理由進行更改了。

無用if-else指令的可怕代碼示例

此代碼唯一好處是可以嘗試實現一種半CQS式的設計模式。如果你傾向于說“那就應該是一個switch”，那你應該花點時間思考一下軟件開發中到底什么是重要的。Switch對if-else來說完全無關緊要。

你每時每刻都會受到新要求的打擊，誰曾想到呢?你曾以為不會發生任何事情。對你的要求現在是這樣的：

你是否真的要通過添加其他枚舉值并附加兩個else-if語句來實現這兩個新原因下的用戶更新?如果決定走這條錯路，結果就會是下面這樣。

復雜的、令人頭痛的分支

這種實現本質上是貧瘠的多態性。除了不斷地添加額外的分支(這本身是一個值得懷疑的實踐)之外，每當需要調試或執行錯誤修復時，都會被完全無關的代碼包圍。

還有一個問題。這個方法標記正在欺騙我們，因為它不只是更新用戶。它還根據更新原因選擇執行哪種算法，甚至知道每種實現。現在顯而易見，這種方法負有大量責任。

我相信這個例子加深了一切關于if-else和switch的可怕印象。讓我們看看如何避免這種討厭的方法。

重構為多態執行非常容易。把基于分支的凌亂代碼重構為內聚的、簡單的、吻合實際需求的類。在有人說害怕使用類之前，筆者要先澄清一件事。實例化新類的成本通常可以忽略不計，在遇到瓶頸之前，請不要嘗試優化代碼。

我們可以做得更好，可以編寫可讀的、可維護的、靈活的代碼。通過用多態執行代替傳統的分支，類與它管理的需求之間有了明確的聯系。具有明確職責的簡單、高度凝聚力的類易于維護。檢測和糾正缺陷變得輕而易舉。最重要的是，軟件可以輕松容納新功能，而無需修改現有類。

讓我們開始重構。來看看不使用if-then-else或switch能做得多好。UpdateAsync(Reason，User)現在變得如此簡單。

簡化的UpdateAsync方法實現

請注意，你現在使用的是接口參數而不是枚舉。現在，該方法委托了知道如何對特定對象執行更新的職責。IUpdateReason的具體實現如下所示，構造函數參數和方法實現的細節不多做贅述。

UpdateReason接口及其具體實現

每個類都完全符合其管理的要求。與過時方法相比，調試，修復錯誤和測試現在要容易多。在這種情況下，任何新要求都會產生一個專門的類。

我們可以輕松地停在這里，結束一天的工作。你重構了繁瑣的分支，并將其替換為多態。你的代碼現在是面向對象的，并且易于維護。但也可以選擇進行最后一步。UpdateAsync(Reason，User)現在有些多余。為了解決這個問題，我們不再進行重構——我們正在重新設計系統的各個部分。

在這種情況下，創建命令對象和命令處理程序是有意義的。它將簡化調用代碼，因為它只調度了諸如UpdateUserAddress之類的命令，并且將調用相應的處理程序的操作。

[[343988]]

圖源：unsplash

在發現更合適的多態方法之前，傳統的分支通常是學生的工具。但毫無疑問，if-then-else和switch會使代碼難以閱讀、維護和調整。下次要使用傳統的多路分支來實現功能時，請花點時間分析如何利用多態性和現代方法，這樣可以讓你事半功倍。