在js開發中，如何減小if else語句的使用

那麼問題來了，在js開發中，如何減小if else語句的使用

代碼中嵌套的if/else結構每每致使代碼不美觀，也不易於理解。面向過程的開發中代碼有大量的IF ELSE，在java中能夠用一些設計模式替換掉這些邏輯，那麼在js中是否也有相似的方法用來儘量減小代碼中的if/else嵌套呢？前端

有人認爲：if else多就多唄，只要可讀性強，維護起來方便。jQuery.fn.init裏就是一堆if else判斷，難道要質疑jQuery做者的水平了？
並非說if else多就很差，關鍵是看用的地方，jQuery.fn.init裏除了if else判斷簡潔點，難道要改爲switch？就算用工廠模式，還不是得作大量的if判斷。java

代碼整潔強迫症患者必需要來個拋磚引玉：程序員

1.

if(a爲真){
    a=a
}else{
    a=b
}

可寫成：a = a || bajax

2.

if(a==b){
    a=c
}else{
    a=d
}

可寫成：a = (a==b) ? c : dexpress

3.

後臺接口一般會返回這種數據：
fruit: 0 // 0=蘋果，1=梨子，2=桔子，3=檸檬，4=芒果...
這時寫if...else是最痛苦的。從衝哥那偷來個方法：後端

var _f = ['蘋果','梨子','桔子','檸檬','芒果'];
shuiguo = _f[fruit];

建議：

第一步：優化if邏輯

人們考慮的東西到時候，都會把最可能發生的狀況先作好準備。優化if邏輯的時候也能夠這樣想：把最可能出現的條件放在前面，把最不可能出現的條件放在後面，這樣程序執行時總會按照帶啊名的前後順序逐一檢測全部的條件，知道發現匹配的條件纔會中止繼續檢測。設計模式

if的優化目標：最小化找到分支以前所判斷條件體的數量。if優化的方法：將最多見的條件放在首位。服務器

if (i < 5) {
    // 執行一些代碼
 } else if (i > 5 && i < 10) {
    // 執行一些代碼
 } else {
    // 執行一些代碼
 }

例如上面這個例子，只有在i值常常出現小於5的時候是最優化的。若是i值常常大於或者等於10的話，那麼在進入正確的分支以前，就必須兩次運算條件體，致使表達式的平均運算時間增長。if中的條件體應該老是按照從最大機率到最小几率排列，以保證理論速度最快。函數

第二步：儘可能少使用else

若是在函數中，可使用 if + return，先判斷錯誤條件，而後立馬結束函數，防止進入 else 分支。性能

舉個簡單的例子，後端返回數據，前端根據狀態進行不一樣操做

$.ajax().done(function (res) {
    if (res.state === 'SUCCESS') {
        //TODO
    } else if (res.state === 'FAIL') {
        //TODO
    } else {
        //TODO
    }
});

這裏用if else不挺好的麼，有啥問題麼？不過我我的傾向於switch。

解決方法：

1. switch/case

switch和if else在性能上是沒有什麼區別的，主要仍是根據需求進行分析和選擇。

• 若是條件較小的話選用if else比較合適。

• 相反，條件數量較大的話，就建議選用switch。

通常來講，if else適用於兩個離散的值或者不一樣的值域。若是判斷多個離散值，使用switch更加合適。

在大多數的狀況下switch比if else運行的更加快。

在大多數狀況下，switch的性能不會比if else低。switch的確在實質上跟if else if 徹底同樣的效果，不過在不少狀況下，使用switch要比if else方便很多

好比經典的值等分支，匹配一些狀態常量的時候，比if else結構方便許多，不用反覆寫xx == yy

$.ajax().done(function (res) {
    switch (res.state) {
        case 'SUCCESS':
            //TODO
            break;
        case 'FAIL':
            //TODO
            break;
        default :
            //TODO
    }
});

注意：千萬不要忘記在每個case語句後面放一個break語句。也能夠放一個return或者throw。case語句匹配expression是用===而不是==。

2.hash 表

if (key == "Apple") {
    val = "Jobs";
} else if (key == "microsoft"){
    val = "Gates";
} else if (key == "Google"){
    val = "Larry";
}

這個也能夠用 switch case 解決，不過推薦的方法是 hash 表：

var ceos = {"Apple":"Jobs", "microsoft":"Gates", "Google":"Larry"};
val = ceos[key];

3.重構，用 OO 裏面的繼承或者組合

1.若是是狗，則汪汪
2.若是是貓，則喵喵
3.若是是羊，則咩咩
4.若是是鴨，則嘎嘎

能夠重構一下，改爲 OO。

*定義類： 動物（或者接口）
*定義方法：叫
*定義子類：狗、貓、羊、鴨
*重寫方法 ----  叫

也就是說將同的判斷按照功能，寫成函數，這樣也便於閱讀

好比我有一個方法根據類型獲取名稱，用if else會這樣

function getName(type) {
    if (type === 'monkey') {
        return 'monkey name';
    } else if (type === 'cat') {
        return 'cat name';
    } else {
        return 'dog name';
    }
}

若是寫成函數，改爲下面的會更好

function getName(type) {
    var data = {
        monkey: 'monkey name',
        cat: 'cat name',
        dog: 'dog name'
    }

    return data[type] ? data[type] : data['dog'];
}

硬要把設計模式添加到JS裏不是不能夠，可是要看狀況。生搬硬套過來的東西然並卵啊。
寫代碼記住三個字便可，短簡易。代碼短，讀起來簡單，維護容易，若是在性能和代碼長度上二選一，我確定選代碼短，性能不行，加臺服務器就是了。而冗長的代碼並非加個程序員就能搞定的。

保持着這個心態寫代碼，寫出的東西離設計模式也不會差太多了。

多說一句：存在必有其價值，不能說if else多了就很差，凡事無絕對，適合A的未必就適合B，每一個東西都有其實現的場景。同理改寫設計模式未必就是最棒的，聽起來高大上點而已。