代碼中嵌套的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
代碼整潔強迫症患者必需要來個拋磚引玉:程序員
if(a爲真){ a=a }else{ a=b }
可寫成:a = a || bajax
if(a==b){ a=c }else{ a=d }
可寫成:a = (a==b) ? c : dexpress
後臺接口一般會返回這種數據:
fruit: 0 // 0=蘋果,1=梨子,2=桔子,3=檸檬,4=芒果...
這時寫if...else是最痛苦的。從衝哥那偷來個方法:後端
var _f = ['蘋果','梨子','桔子','檸檬','芒果']; shuiguo = _f[fruit];
人們考慮的東西到時候,都會把最可能發生的狀況先作好準備。優化if邏輯的時候也能夠這樣想:把最可能出現的條件放在前面,把最不可能出現的條件放在後面,這樣程序執行時總會按照帶啊名的前後順序逐一檢測全部的條件,知道發現匹配的條件纔會中止繼續檢測。設計模式
if
的優化目標:最小化找到分支以前所判斷條件體的數量。if優化的方法:將最多見的條件放在首位。服務器
if (i < 5) { // 執行一些代碼 } else if (i > 5 && i < 10) { // 執行一些代碼 } else { // 執行一些代碼 }
例如上面這個例子,只有在i
值常常出現小於5的時候是最優化的。若是i值常常大於或者等於10的話,那麼在進入正確的分支以前,就必須兩次運算條件體,致使表達式的平均運算時間增長。if
中的條件體應該老是按照從最大機率到最小几率排列,以保證理論速度最快。函數
若是在函數中,可使用 if + return
,先判斷錯誤條件,而後立馬結束函數,防止進入 else
分支。性能
舉個簡單的例子,後端返回數據,前端根據狀態進行不一樣操做
$.ajax().done(function (res) { if (res.state === 'SUCCESS') { //TODO } else if (res.state === 'FAIL') { //TODO } else { //TODO } });
這裏用if else不挺好的麼,有啥問題麼?不過我我的傾向於switch。
解決方法:
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是用===而不是==。
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];
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,每一個東西都有其實現的場景。同理改寫設計模式未必就是最棒的,聽起來高大上點而已。