你還在用if/else嗎？

前提

我們在日常開發當中經常會遇到復雜的條件判斷，一般的做法是用if/else，或者優雅一點的寫法是用switch語句來實現多個條件的判斷，這樣的話會有很多問題，隨著判斷條件的增加，代碼中if/else或switch會變得越來越臃腫，如何使用更優雅的方式來實現呢，本文帶你來試一下。

案例

先看一段代碼

通過代碼可以看到這個按鈕的點擊邏輯：根據不同活動狀態做兩件事情，發送日志埋點和跳轉到對應頁面，大家可以很輕易的提出這段代碼的改寫方案，switch出場：

這樣看起來比if/else清晰多了，細心的同學也發現了小技巧，case 2和case 3邏輯一樣的時候，可以省去執行語句和break，則case 2的情況自動執行case 3的邏輯。

這是我們日常開發中基本大多數同學的寫法，這種寫法可以嗎，當然可以，只是不夠優雅，這幾天在看左耳聽風的專欄，在讀到編程的本質一章的時候，文中有這樣一個觀點任何算法都會有兩個部分， 一個是 Logic 部分，這是用來解決實際問題的。另一個是 Control 部分，這是用來決定用什么策略來解決問題。Logic 部分是真正意義上的解決問題的算法，而 Control 部分只是影響解決這個問題的效率。程序運行的效率問題和程序的邏輯其實是沒有關系的。我們認為 ,如果將 Logic 和 Control 部分有效地分開,那么代碼就會變得更容易改進和維護,那么下面我們就用這種思想去試著分離一下代碼，可以分離成如下形式

這樣的形式其實就是DSL(Domain Specific Language)+一個DSL的解析器，這樣，DSL 的描述是“Logic”，而我們的onButtonClick則成了Control，代碼大大簡化了。由此我們可以總結出如下的思想：

好的繼續我們的優化，是不是還有其他寫法呢？有的：

我們需要把問題升級一下，以前按鈕點擊時候只需要判斷status，現在還需要判斷用戶的身份：

這了我不寫每個判斷里的具體邏輯了，因為代碼太冗長了。 原諒我又用了if/else，因為我看到很多人依然在用if/else寫這種大段的邏輯判斷。 從上面的例子我們可以看到，當你的邏輯升級為二元判斷時，你的判斷量會加倍，你的代碼量也會加倍，這時怎么寫更清爽呢？

上述代碼核心邏輯是：把兩個條件拼接成字符串，并通過以條件拼接字符串作為鍵，以處理函數作為值的Map對象進行查找并執行，這種寫法在多元條件判斷時候尤其好用。

當然上述代碼如果用Object對象來實現也是類似的：

如果有些同學覺得把查詢條件拼成字符串有點別扭，那還有一種方案，就是用Map對象，以Object對象作為key：

是不是又高級了一點點？

這里也看出來Map與Object的區別，Map可以用任何類型的數據作為key。

我們現在再將難度升級一點點，假如guest情況下，status1-4的處理邏輯都一樣怎么辦，最差的情況是這樣：

好一點的寫法是將處理邏輯函數進行緩存：

這樣寫已經能滿足日常需求了，但認真一點講，上面重寫了4次functionA還是有點不爽，假如判斷條件變得特別復雜，比如identity有3種狀態，status有10種狀態，那你需要定義30條處理邏輯，而往往這些邏輯里面很多都是相同的，這似乎也是筆者不想接受的，那么這里要怎么處理呢，可以使用正則表達式，如下:

這里Map的優勢更加凸顯，可以用正則類型作為key了，這樣就有了無限可能，假如需求變成，凡是guest情況都要發送一個日志埋點，不同status情況也需要單獨的邏輯處理，那我們可以這樣寫:

也就是說利用數組循環的特性，符合正則條件的邏輯都會被執行，那就可以同時執行公共邏輯和單獨邏輯，因為正則的存在，你可以打開想象力解鎖更多的玩法，本文就不贅述了。

總結

本文的核心就是講邏輯(Logic)和Control(控制)如何分離，如果所有的程序都能夠很好的分離，那么代碼的可維護性就會大大提高，因為代碼不僅僅要運行還要寫來給人看的，這也是編程的意義。

總結

以上是生活随笔為你收集整理的if else if else语句格式_你还在用if/else吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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