減少該死的 if else 嵌套！

• 2019 年 11 月 4 日
• 筆記

不知大家有沒遇到過像「橫放著的金字塔」一樣的if else嵌套：

我並沒誇大其詞，我是真的遇到過了！嵌套6、7層，一個函數幾百行，簡！直！看！死！人！

if else作為每種程式語言都不可或缺的條件語句，我們在編程時會大量的用到。但if else一般不建議嵌套超過三層，如果一段程式碼存在過多的if else嵌套，程式碼的可讀性就會急速下降，後期維護難度也大大提高。所以，我們程式設計師都應該盡量避免過多的if else嵌套。下面將會談談我在工作中如何減少if else嵌套的。

正文

在談我的方法之前，不妨先用個例子來說明if else嵌套過多的弊端。

想像下一個簡單分享的業務需求：支援分享鏈接、圖片、文本和圖文，分享結果回調給用戶（為了不跑題，這裡簡略了業務，實際複雜得多）。當接手到這麼一個業務時，是不是覺得很簡單，稍動下腦就可以動手了：

先定義分享的類型、分享Bean和分享回調類：

好了，然後在定義個分享介面，對每種類型分別進行分享就ok了：

到此，簡單的分享模型就做出來了。有沒問題？老實說，如果沒什麼追求的話，還真沒什麼問題，至少思路是清晰的。但一周後呢？一個月後呢？或者一年後呢？share方法的分支有15條，這意味著你每次回看程式碼得讓自己的大腦變成微型的處理器，考慮15種情況。如果出現bug，你又得考慮15種情況，並15種情況都要測試下。再如果現在需要加多分享小影片功能，你又得添加多3個分支，還要改程式碼，一點都不「開放-閉合」。再再如果後面項目交接給他人跟進，他人又要把自己大腦變成處理器來想每個分支的作用，我敢肯定有百分之八十的人都會吐槽程式碼。

我們程式設計師的腦力不應該花費在無止境的分支語句里的，應該專註於業務本身。所以我們很有必要避免寫出多分支嵌套的語句。好的，我們來分析下上面的程式碼多分支的原因：

1、空值判斷

2、業務判斷

3、狀態判斷

幾乎所有的業務都離不開這幾個判斷，從而導致if else嵌套過多。那是不是沒辦法解決了？答案肯定不是的。

上面的程式碼我是用java寫的，對於java程式設計師來說，空值判斷簡直使人很沮喪，讓人身心疲憊。上面的程式碼每次回調都要判斷一次listener是否為空，又要判斷用戶傳入的ShareItem是否為空，還要判斷ShareItem裡面的欄位是否為空......

對於這種情況，我採用的方法很簡單：介面分層。

減少 if else 方法一：介面分層

所謂介面分層指的是：把介面分為外部和內部介面，所有空值判斷放在外部介面完成，只處理一次；而內部介面傳入的變數由外部介面保證不為空，從而減少空值判斷。

來，看程式碼更加直觀：

可以看到，上面的程式碼分為外部介面share和內部介面shareImpl，ShareItem和ShareListener的判斷都放在share里完成，那麼shareImpl就減少了if else的嵌套了，相當於把if else分攤了。這樣一來，程式碼的可讀性好很多，嵌套也不超過3層了。

但可以看到，shareImpl里還是包含分享類型的判斷，也即業務判斷，我們都清楚產品經理的腦洞有多大了，分享的類型隨時會改變或添加。嗯說到這裡相信大家都想到用多態了。多態不但能應付業務改變的情況，也可以用來減少if else的嵌套。

減少 if else 方法二：多態

利用多態，每種業務單獨處理，在介面不再做任何業務判斷。把ShareItem抽象出來，作為基礎類，然後針對每種業務各自實現其子類：

（注意：上面每個子類的構造方法還對每個欄位做了空值處理，為空的話，賦值default，這樣如果用戶傳了空值，在調試就會發現問題。）

實現了多態後，分享介面的就簡潔多了：

嘻嘻，怎樣，內部介面一個if else都沒了，是不是很酷~ 如果這個分享功能是自己App裡面的功能，不是第三方SDK，到這裡已經沒問題了。但如果是第三方分享SDK的功能的話，這樣暴露給用戶的類增加了很多（各ShareItem的子類，相當於把if else拋給用戶了），用戶的接入成本提高，違背了「迪米特原則」了。

處理這種情況也很簡單，再次封裝一層即可。把ShareItem的子類的訪問許可權降低，在暴露給用戶的主類里定義幾個方法，在內部幫助用戶創建具體的分享類型，這樣用戶就無需知道具體的類了：

或者有人會說，這樣用戶也需額外了解多幾個方法。我個人覺得讓用戶了解多幾個方法好過了解多幾個類，而已方法名一看就能知道意圖，成本還是挺小，是可以接受的。

其實這種情況，更多人想到的是使用工廠模式。嗯，工廠模式能解決這個問題（其實也需要用戶額外了解多幾個type類型），但工廠模式難免又引入分支，我們可以用Map消除分支。

減少 if else 方法三：使用Map替代分支語句

把所有分享類型預先快取在Map里，那麼就可以直接get獲取具體類型，消除分支：

這種方式跟上面分為幾個方法的方式各有利弊，看大家取捨了~

寫在最後

講到這裡大家有沒收穫呢？總結下減少if else的方法：

1、把介面分為外部和內部介面，所有空值判斷放在外部介面完成；而內部介面傳入的變數由外部介面保證不為空，從而減少空值判斷。

2、利用多態，把業務判斷消除，各子類分別關注自己的實現，並實現子類的創建方法，避免用戶了解過多的類。

3、把分支狀態資訊預先快取在Map里，直接get獲取具體值，消除分支。

好了，到此就介紹完了，希望大家以後寫程式碼能注意，有則避之，無則加勉。希望大家寫的程式碼越來越簡潔~