前提

我們編寫js代碼時經(jīng)常遇到復(fù)雜邏輯判斷的情況，通?？梢杂胕f/else或者switch來實(shí)現(xiàn)多個條件判斷，但這樣會有個問題，隨著邏輯復(fù)雜度的增加，代碼中的if/else/switch會變得越來越臃腫，越來越看不懂，那么如何更優(yōu)雅的寫判斷邏輯。

舉個例子

先看一段代碼

通過代碼可以看到這個按鈕的點(diǎn)擊邏輯：根據(jù)不同活動狀態(tài)做兩件事情，發(fā)送日志埋點(diǎn)和跳轉(zhuǎn)到對應(yīng)頁面，可以很輕易的提出這段代碼的改寫方案，switch出場：

嗯，這樣看起來比if/else清晰多了，其實(shí)case 2和case 3邏輯一樣的時候，可以省去執(zhí)行語句和break，則case 2的情況自動執(zhí)行case 3的邏輯。

那么，就有更簡單的寫法：

上面代碼確實(shí)看起來更清爽了，這種方法的聰明之處在于：將判斷條件作為對象的屬性名，將處理邏輯作為對象的屬性值，在按鈕點(diǎn)擊的時候，通過對象屬性查找的方式來進(jìn)行邏輯判斷，這種寫法特別適合一元條件判斷的情況。

是不是還有其他寫法呢？有的：

這樣寫用到了es6里的Map對象，是不是更爽了？Map對象和Object對象有什么區(qū)別呢？

一個對象通常都有自己的原型，所以一個對象總有一個"prototype"鍵。

一個對象的鍵只能是字符串或者Symbols，但一個Map的鍵可以是任意值。

可以通過size屬性很容易地得到一個Map的鍵值對個數(shù)，而對象的鍵值對個數(shù)只能手動確認(rèn)。

還可以把問題升級一下，以前按鈕點(diǎn)擊時候只需要判斷status，現(xiàn)在還需要判斷用戶的身份：

（原諒我不寫每個判斷里的具體邏輯了，因?yàn)榇a太冗長了。

原諒我又用了if/else，因?yàn)槲铱吹胶芏嗳艘廊辉谟胕f/else寫這種大段的邏輯判斷。）

從上面的例子可以看到，當(dāng)邏輯升級為二元判斷時，判斷量會加倍，代碼量也會加倍，這時怎么寫更清爽呢？

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

當(dāng)然上述代碼如果用Object對象來實(shí)現(xiàn)也是類似的：

如果覺得把查詢條件拼成字符串有點(diǎn)別扭，那還有一種方案，就是用Map對象，以O(shè)bject對象作為key：

是不是又高級了一點(diǎn)點(diǎn)？

這里也看出來Map與Object的區(qū)別，Map可以用任何類型的數(shù)據(jù)作為key。

現(xiàn)在再將難度升級一點(diǎn)點(diǎn)，假如guest情況下，status1-4的處理邏輯都一樣怎么辦，最差的情況是這樣：

好一點(diǎn)的寫法是將處理邏輯函數(shù)進(jìn)行緩存：

這樣寫已經(jīng)能滿足日常需求了，但認(rèn)真一點(diǎn)講，上面重寫了4次functionA還是有點(diǎn)不爽，假如判斷條件變得特別復(fù)雜，比如identity有3種狀態(tài)，status有10種狀態(tài)，那就需要定義30條處理邏輯，而往往這些邏輯里面很多都是相同的，這似乎也是筆者不想接受的，那可以這樣實(shí)現(xiàn):

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

也就是說利用數(shù)組循環(huán)的特性，符合正則條件的邏輯都會被執(zhí)行，那就可以同時執(zhí)行公共邏輯和單獨(dú)邏輯，因?yàn)檎齽t的存在，你可以打開想象力解鎖更多的玩法，本文就不贅述了。

總結(jié)

本文已經(jīng)教你了8種邏輯判斷寫法，包括：

if/else

switch

一元判斷時：存到Object里

一元判斷時：存到Map里

多元判斷時：將condition拼接成字符串存到Object里

多元判斷時：將condition拼接成字符串存到Map里

多元判斷時：將condition存為Object存到Map里

多元判斷時：將condition寫作正則存到Map里

至此，本文也將告一段落，要記得JavaScript里的判斷不只是有if/else/switch。