優化代碼中大量的if/else，你有什麼方案?

一個快速迭代的項目，時間久了以後，代碼中可能會充斥着大量的if/else，嵌套六、7層，一個函數幾百行，簡！直！看！死！人！

其實這種還算好的，更嚴重的嵌套我也見過，接手到這種項目的人，心裏應該是絕望的。

出現這種狀況的緣由不少

• 設計不夠完善
• 需求考慮不徹底
• 開發人員變更

但最爲致命的是「懶」，沒有夢想是件很可怕的事情！

前期迭代懶得優化，來一個需求，加一個if，長此以往，就串成了一座金字塔。

當代碼已經複雜到難以維護的程度以後，只能狠下心重構優化。那，有什麼方案能夠優雅的優化掉這些多餘的if/else?

01 提早return

這是判斷條件取反的作法，代碼在邏輯表達上會更清晰，看下面代碼：

其實，每次看到上面這種代碼，我都內心抓癢，徹底能夠先判斷!condition，幹掉else。

02 策略模式

有這麼一種場景，根據不一樣的參數走不一樣的邏輯，其實這種場景很常見。 最通常的實現：

看上面代碼，有4種策略，有兩種優化方案。

2.1 多態

具體策略對象存放在一個Map中，優化後的實現

上面這種優化方案有一個弊端，爲了可以快速拿到對應的策略實現，須要map對象來保存策略，當添加一個新策略的時候，還須要手動添加到map中，容易被忽略。

2.2 枚舉

發現不少同窗不知道在枚舉中能夠定義方法，這裏定義一個表示狀態的枚舉，另外能夠實現一個run方法。

從新定義策略枚舉

經過枚舉優化以後的代碼以下

03 學會使用 Optional

Optional主要用於非空判斷，因爲是jdk8新特性，因此使用的不是特別多，可是用起來真的爽。 使用以前：

若是登陸用戶爲空，執行action1，不然執行action 2，使用Optional優化以後，讓非空校驗更加優雅，間接的減小if操做

04 數組小技巧

來自google解釋，這是一種編程模式，叫作表驅動法，本質是從表裏查詢信息來代替邏輯語句，好比有這麼一個場景，經過月份來獲取當月的天數，僅做爲案例演示，數據並不嚴謹。 通常的實現：

優化後的代碼

05 結語

if else做爲每種編程語言都不可或缺的條件語句，在編程時會大量的用到。通常建議嵌套不要超過三層，若是一段代碼存在過多的if else嵌套，代碼的可讀性就會急速降低，後期維護難度也大大提升。 若是你還有其它小技巧，歡迎留言！！！