全文共2111字，預計學習時長6分鐘
筆者常常看到許多分支發生在枚舉或其他離散值上，當某些開發人員被要求不要使用if-then-else時，甚至會感到惱火。if-else和switch當然可以生成簡潔的代碼，你的軟體不應該由最少的行組成，也不必犧牲可讀性、可維護性或靈活性。
在if-then-else語句中使用枚舉的後果是什麼呢？基於離散值的分支會使軟體難以更改。每個新功能都要求跟蹤分支發生的位置，並相應地修改現有代碼。
這絕對不是我們想要的方式。這或許是使代碼正常工作的第一步，但隨著你不斷改進代碼，switch和if-then-else肯定早已不復存在。
我必須要說，使用if-else和switch進行分支的傳統方法已過時。它不可靠、不靈活。傳統方法中沒有面向對象的內容。但是它仍在蓬勃發展，因為學生們被迫認為它是正確的，甚至是最佳實踐。代碼是有效的，但你可以做得更好。
設想一下這個問題。假設出於某種原因，必須用一種方法來更新用戶。為了簡單起見，用戶只出於兩種理由需要在系統中被更新。
你可以在以下代碼段中實現這兩種簡單的情況。花一點時間閱讀這段設計欠佳的代碼吧，許多高級開發人員都把此當作噩夢，它甚至被認為是引發「十年怕井繩」的那條蛇。
是的，我看到過這樣瘋狂的野生代碼。這是一個非常幼稚的操作，它假定用戶永遠沒有那麼多理由進行更改了。
此代碼唯一好處是可以嘗試實現一種半CQS式的設計模式。如果你傾向於說「那就應該是一個switch」，那你應該花點時間思考一下軟體開發中到底什麼是重要的。Switch對if-else來說完全無關緊要。
你每時每刻都會受到新要求的打擊，誰曾想到呢？你曾以為不會發生任何事情。對你的要求現在是這樣的：
你是否真的要通過添加其他枚舉值並附加兩個else-if語句來實現這兩個新原因下的用戶更新？如果決定走這條錯路，結果就會是下面這樣。
這種實現本質上是貧瘠的多態性。除了不斷地添加額外的分支（這本身是一個值得懷疑的實踐）之外，每當需要調試或執行錯誤修復時，都會被完全無關的代碼包圍。
還有一個問題。這個方法標記正在欺騙我們，因為它不只是更新用戶。它還根據更新原因選擇執行哪種算法，甚至知道每種實現。現在顯而易見，這種方法負有大量責任。
我相信這個例子加深了一切關於if-else和switch的可怕印象。讓我們看看如何避免這種討厭的方法。
重構為多態執行非常容易。把基於分支的凌亂代碼重構為內聚的、簡單的、吻合實際需求的類。在有人說害怕使用類之前，筆者要先澄清一件事。實例化新類的成本通常可以忽略不計，在遇到瓶頸之前，請不要嘗試優化代碼。
我們可以做得更好，可以編寫可讀的、可維護的、靈活的代碼。通過用多態執行代替傳統的分支，類與它管理的需求之間有了明確的聯繫。具有明確職責的簡單、高度凝聚力的類易於維護。檢測和糾正缺陷變得輕而易舉。最重要的是，軟體可以輕鬆容納新功能，而無需修改現有類。
讓我們開始重構。來看看不使用if-then-else或switch能做得多好。UpdateAsync（Reason，User）現在變得如此簡單。
請注意，你現在使用的是接口參數而不是枚舉。現在，該方法委託了知道如何對特定對象執行更新的職責。IUpdateReason的具體實現如下所示，構造函數參數和方法實現的細節不多做贅述。
每個類都完全符合其管理的要求。與過時方法相比，調試，修復錯誤和測試現在要容易多。在這種情況下，任何新要求都會產生一個專門的類。
我們可以輕鬆地停在這裡，結束一天的工作。你重構了繁瑣的分支，並將其替換為多態。你的代碼現在是面向對象的，並且易於維護。但也可以選擇進行最後一步。UpdateAsync（Reason，User）現在有些多餘。為了解決這個問題，我們不再進行重構——我們正在重新設計系統的各個部分。
在這種情況下，創建命令對象和命令處理程序是有意義的。它將簡化調用代碼，因為它只調度了諸如UpdateUserAddress之類的命令，並且將調用相應的處理程序的操作。
在發現更合適的多態方法之前，傳統的分支通常是學生的工具。但毫無疑問，if-then-else和switch會使代碼難以閱讀、維護和調整。下次要使用傳統的多路分支來實現功能時，請花點時間分析如何利用多態性和現代方法，這樣可以讓你事半功倍。
留言點讚關注
我們一起分享AI學習與發展的乾貨
如轉載，請後臺留言，遵守轉載規範