本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)。

10年的鹿邑網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整鹿邑建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“鹿邑網(wǎng)站設(shè)計(jì)”,“鹿邑網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

筆者常?？吹皆S多分支發(fā)生在枚舉或其他離散值上，當(dāng)某些開發(fā)人員被要求不要使用if-then-else時(shí)，甚至?xí)械綈阑稹f-else和switch當(dāng)然可以生成簡潔的代碼，你的軟件不應(yīng)該由最少的行組成，也不必犧牲可讀性、可維護(hù)性或靈活性。

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

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

我必須要說，使用if-else和switch進(jìn)行分支的傳統(tǒng)方法已過時(shí)。它不可靠、不靈活。傳統(tǒng)方法中沒有面向?qū)ο蟮膬?nèi)容。但是它仍在蓬勃發(fā)展，因?yàn)閷W(xué)生們被迫認(rèn)為它是正確的，甚至是最佳實(shí)踐。代碼是有效的，但你可以做得更好。

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

最初的一組要求

你可以在以下代碼段中實(shí)現(xiàn)這兩種簡單的情況。花一點(diǎn)時(shí)間閱讀這段設(shè)計(jì)欠佳的代碼吧，許多高級開發(fā)人員都把此當(dāng)作噩夢，它甚至被認(rèn)為是引發(fā)“十年怕井繩”的那條蛇。

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

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

此代碼唯一好處是可以嘗試實(shí)現(xiàn)一種半CQS式的設(shè)計(jì)模式。如果你傾向于說“那就應(yīng)該是一個(gè)switch”，那你應(yīng)該花點(diǎn)時(shí)間思考一下軟件開發(fā)中到底什么是重要的。Switch對if-else來說完全無關(guān)緊要。

你每時(shí)每刻都會(huì)受到新要求的打擊，誰曾想到呢?你曾以為不會(huì)發(fā)生任何事情。對你的要求現(xiàn)在是這樣的：

你是否真的要通過添加其他枚舉值并附加兩個(gè)else-if語句來實(shí)現(xiàn)這兩個(gè)新原因下的用戶更新?如果決定走這條錯(cuò)路，結(jié)果就會(huì)是下面這樣。

復(fù)雜的、令人頭痛的分支

這種實(shí)現(xiàn)本質(zhì)上是貧瘠的多態(tài)性。除了不斷地添加額外的分支(這本身是一個(gè)值得懷疑的實(shí)踐)之外，每當(dāng)需要調(diào)試或執(zhí)行錯(cuò)誤修復(fù)時(shí)，都會(huì)被完全無關(guān)的代碼包圍。

還有一個(gè)問題。這個(gè)方法標(biāo)記正在欺騙我們，因?yàn)樗恢皇歉掠脩?。它還根據(jù)更新原因選擇執(zhí)行哪種算法，甚至知道每種實(shí)現(xiàn)?，F(xiàn)在顯而易見，這種方法負(fù)有大量責(zé)任。

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

重構(gòu)為多態(tài)執(zhí)行非常容易。把基于分支的凌亂代碼重構(gòu)為內(nèi)聚的、簡單的、吻合實(shí)際需求的類。在有人說害怕使用類之前，筆者要先澄清一件事。實(shí)例化新類的成本通?？梢院雎圆挥?jì)，在遇到瓶頸之前，請不要嘗試優(yōu)化代碼。

我們可以做得更好，可以編寫可讀的、可維護(hù)的、靈活的代碼。通過用多態(tài)執(zhí)行代替?zhèn)鹘y(tǒng)的分支，類與它管理的需求之間有了明確的聯(lián)系。具有明確職責(zé)的簡單、高度凝聚力的類易于維護(hù)。檢測和糾正缺陷變得輕而易舉。最重要的是，軟件可以輕松容納新功能，而無需修改現(xiàn)有類。

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

簡化的UpdateAsync方法實(shí)現(xiàn)

請注意，你現(xiàn)在使用的是接口參數(shù)而不是枚舉?，F(xiàn)在，該方法委托了知道如何對特定對象執(zhí)行更新的職責(zé)。IUpdateReason的具體實(shí)現(xiàn)如下所示，構(gòu)造函數(shù)參數(shù)和方法實(shí)現(xiàn)的細(xì)節(jié)不多做贅述。

UpdateReason接口及其具體實(shí)現(xiàn)

每個(gè)類都完全符合其管理的要求。與過時(shí)方法相比，調(diào)試，修復(fù)錯(cuò)誤和測試現(xiàn)在要容易多。在這種情況下，任何新要求都會(huì)產(chǎn)生一個(gè)專門的類。

我們可以輕松地停在這里，結(jié)束一天的工作。你重構(gòu)了繁瑣的分支，并將其替換為多態(tài)。你的代碼現(xiàn)在是面向?qū)ο蟮?，并且易于維護(hù)。但也可以選擇進(jìn)行最后一步。UpdateAsync(Reason，User)現(xiàn)在有些多余。為了解決這個(gè)問題，我們不再進(jìn)行重構(gòu)——我們正在重新設(shè)計(jì)系統(tǒng)的各個(gè)部分。

在這種情況下，創(chuàng)建命令對象和命令處理程序是有意義的。它將簡化調(diào)用代碼，因?yàn)樗徽{(diào)度了諸如UpdateUserAddress之類的命令，并且將調(diào)用相應(yīng)的處理程序的操作。

圖源：unsplash

在發(fā)現(xiàn)更合適的多態(tài)方法之前，傳統(tǒng)的分支通常是學(xué)生的工具。但毫無疑問，if-then-else和switch會(huì)使代碼難以閱讀、維護(hù)和調(diào)整。下次要使用傳統(tǒng)的多路分支來實(shí)現(xiàn)功能時(shí)，請花點(diǎn)時(shí)間分析如何利用多態(tài)性和現(xiàn)代方法，這樣可以讓你事半功倍。

當(dāng)前文章：從6行到92行：If-Else是貧瘠的多態(tài)性
URL鏈接：http://uogjgqi.cn/article/cohjphh.html