今天分享的文章不僅僅介紹9種應對代碼中如果 if-else 比較多，閱讀起來比較困難，維護起來也比較麻煩，也容易出 Bug的情況，但是有些人也會有不同的看法！
正文如下:

觀點一（靈劍）：

前期迭代懶得優(yōu)化，來一個需求，加一個if，久而久之，就串成了一座金字塔。

當代碼已經(jīng)復雜到難以維護的程度之后，只能狠下心重構優(yōu)化。那，有什么方案可以優(yōu)雅的優(yōu)化掉這些多余的if/else?

1. 提前return

這是判斷條件取反的做法，代碼在邏輯表達上會更清晰，看下面代碼：if?(condition)?{
?//?do?something
}?else?{
??return?xxx;
}
其實，每次看到上面這種代碼，我都心里抓癢，完全可以先判斷!condition，干掉else。if?(!condition)?{
??return?xxx;

}?
//?do?something

2. 策略模式

有這么一種場景，根據(jù)不同的參數(shù)走不同的邏輯，其實這種場景很常見。
最一般的實現(xiàn)：if?(strategy.equals("fast"))?{
??//?快速執(zhí)行
}?else?if?(strategy.equals("normal"))?{
??//?正常執(zhí)行
}?else?if?(strategy.equals("smooth"))?{
??//?平滑執(zhí)行
}?else?if?(strategy.equals("slow"))?{
??//?慢慢執(zhí)行
}
看上面代碼，有4種策略，有兩種優(yōu)化方案。

2.1 多態(tài)

interface?Strategy?{
??void?run()?throws?Exception;
}

class?FastStrategy?implements?Strategy?{
????@Override
????void?run()?throws?Exception?{
????????//?快速執(zhí)行邏輯
????}
}

class?NormalStrategy?implements?Strategy?{
????@Override
????void?run()?throws?Exception?{
????????//?正常執(zhí)行邏輯
????}
}

class?SmoothStrategy?implements?Strategy?{
????@Override
????void?run()?throws?Exception?{
????????//?平滑執(zhí)行邏輯
????}
}

class?SlowStrategy?implements?Strategy?{
????@Override
????void?run()?throws?Exception?{
????????//?慢速執(zhí)行邏輯
????}
}
具體策略對象存放在一個Map中，優(yōu)化后的實現(xiàn)Strategy?strategy?=?map.get(param);
strategy.run();
上面這種優(yōu)化方案有一個弊端，為了能夠快速拿到對應的策略實現(xiàn)，需要map對象來保存策略，當添加一個新策略的時候，還需要手動添加到map中，容易被忽略。

2.2 枚舉

發(fā)現(xiàn)很多同學不知道在枚舉中可以定義方法，這里定義一個表示狀態(tài)的枚舉，另外可以實現(xiàn)一個run方法。public?enum?Status?{
????NEW(0)?{
??????@Override
??????void?run()?{
????????//do?something??
??????}
????},
????RUNNABLE(1)?{
??????@Override
???????void?run()?{
?????????//do?something??
??????}
????};

????public?int?statusCode;

????abstract?void?run();

????Status(int?statusCode){
????????this.statusCode?=?statusCode;
????}
}
重新定義策略枚舉public?enum?Strategy?{
????FAST?{
??????@Override
??????void?run()?{
????????//do?something??
??????}
????},
????NORMAL?{
??????@Override
???????void?run()?{
?????????//do?something??
??????}
????},

????SMOOTH?{
??????@Override
???????void?run()?{
?????????//do?something??
??????}
????},

????SLOW?{
??????@Override
???????void?run()?{
?????????//do?something??
??????}
????};
????abstract?void?run();
}
通過枚舉優(yōu)化之后的代碼如下Strategy?strategy?=?Strategy.valueOf(param);
strategy.run();

3. 學會使用 Optional

Optional主要用于非空判斷，由于是jdk8新特性，所以使用的不是特別多，但是用起來真的爽。使用之前：if?(user?==?null)?{
????//do?action?1
}?else?{
????//do?action2
}
如果登錄用戶為空，執(zhí)行action1，否則執(zhí)行action 2，使用Optional優(yōu)化之后，讓非空校驗更加優(yōu)雅，間接的減少if操作Optional?userOptional?=?Optional.ofNullable(user);
userOptional.map(action1).orElse(action2);

4. 數(shù)組小技巧

來自google解釋，這是一種編程模式，叫做表驅(qū)動法，本質(zhì)是從表里查詢信息來代替邏輯語句，比如有這么一個場景，通過月份來獲取當月的天數(shù)，僅作為案例演示，數(shù)據(jù)并不嚴謹。一般的實現(xiàn)：int?getDays(int?month){
????if?(month?==?1)??return?31;
????if?(month?==?2)??return?29;
????if?(month?==?3)??return?31;
????if?(month?==?4)??return?30;
????if?(month?==?5)??return?31;
????if?(month?==?6)??return?30;
????if?(month?==?7)??return?31;
????if?(month?==?8)??return?31;
????if?(month?==?9)??return?30;
????if?(month?==?10)??return?31;
????if?(month?==?11)??return?30;
????if?(month?==?12)??return?31;
}
優(yōu)化后的代碼int?monthDays[12]?=?{31,?29,?31,?30,?31,?30,?31,?31,?30,?31,?30,?31};
int?getDays(int?month){
????return?monthDays[--month];
}

結(jié)束

if else作為每種編程語言都不可或缺的條件語句，在編程時會大量的用到。一般建議嵌套不要超過三層，如果一段代碼存在過多的if else嵌套，代碼的可讀性就會急速下降，后期維護難度也大大提高。

觀點二（IT技術控）：

不要去過度關注if/else的層數(shù)，而要關注接口語義是否足夠清晰；單純減少if/else的層數(shù)，然后拆出一堆do_logic1, do_logic2…這樣的接口是毫無幫助的。任何一個接口的執(zhí)行過程都可以表示為：輸入 內(nèi)部狀態(tài) -> 輸出這樣的形式，我們分以下幾種情況來討論：輸入、內(nèi)部狀態(tài)、輸出都很簡單，但中間邏輯復雜。比如說一個精心優(yōu)化過的數(shù)值計算程序，可能需要根據(jù)輸入在不同的取值范圍采取不同的策略，還有很多邏輯用來處理會引發(fā)問題（比如除0）的邊界值，這種情況下if/else數(shù)量多是難以避免的，根據(jù)步驟拆分出一些內(nèi)部方法有一定幫助，但也不能完全解決問題。這種情況下最好的做法是寫一篇詳細的文檔，從最原始的數(shù)學模型開始，然后表明什么情況下采取什么樣的計算策略，策略如何推導，知道得到代碼中使用的具體形式，然后給整個方法加上注釋附上文檔地址，并且在每個分支的地方加上注釋指明對應到文檔中哪個公式。這種情況下雖然方法很復雜，但是語義是清晰的，如果不修改實現(xiàn)的話理解語義就行了，如果要修改實現(xiàn)那么需要參考對照文檔中的公式。輸入過于復雜，比如輸入帶有一堆不同的參數(shù)，或者有各種奇怪的flag，每個flag有不同作用。這種情況下首先需要提高接口的抽象層次：如果接口有多個不同作用，需要拆分成不同接口；如果接口內(nèi)部根據(jù)不同參數(shù)進不同分支，需要將這些參數(shù)和對應分支包在Adapter里，使用參數(shù)的地方改寫成Adapter的接口，根據(jù)傳入的Adapter類型不同進入不同的實現(xiàn)；如果接口內(nèi)部有復雜的參數(shù)轉(zhuǎn)換關系，需要改寫成查找表。這種情況下的主要問題是接口本身抽象的有問題，有更清晰的抽象之后，實現(xiàn)也自然沒有那么多if/else了。輸出過于復雜，為了省事一個過程計算出了太多東西，又為了性能加了一堆flag控制是否計算之類。這種情況下需要果斷將方法拆分成多個不同方法，每個方法只返回自己需要的內(nèi)容。如果不同計算之間有共用的內(nèi)部結(jié)果呢？如果這個內(nèi)部結(jié)果計算并不形成瓶頸，只要提取出內(nèi)部方法然后在不同過程中分別調(diào)用即可；如果希望避免重復計算，可以增加一個額外的cache對象作為參數(shù)，cache內(nèi)容對用戶不透明，用戶只保證相同輸入使用同一個cache對象即可，在計算中將中間結(jié)果保存到cache中，下次計算前先檢查有沒有已經(jīng)得到的結(jié)果，就可以避免重復計算了。內(nèi)部狀態(tài)過于復雜。首先檢查狀態(tài)設置的是否合理，是不是有一些本來應該作為輸入?yún)?shù)的東西被放到了內(nèi)部狀態(tài)中（比如用來隱式地在兩個不同方法調(diào)用之間傳遞參數(shù)）？其次，這些狀態(tài)分別控制哪些方面，是否可以分組然后實現(xiàn)到不同的StateManager里面？第三，畫出狀態(tài)轉(zhuǎn)移圖，嘗試將內(nèi)部狀態(tài)分成單層分支，然后分別實現(xiàn)到on_xxx_state這樣的方法里面，然后通過單層的switch或者查找表來調(diào)用。其實通常需要優(yōu)化的都是整體接口抽象，而不是單個接口的實現(xiàn)，單個接口實現(xiàn)不清晰通常是因為接口實現(xiàn)和需求不同構造成的。來源：https://www.zhihu.com/question/344856665版權歸原作者所有，如有侵權，請聯(lián)系刪除。select_card mp_profile_iframe" data-pluginname="mpprofile" data-id="MjM5NDQ0NjM5Mg==" data-headimg="http://mmbiz.qpic.cn/mmbiz_png/XZMicpgcYibXGZlfHyXUq0wvbDaJ3ic0P6E1Gic49tLOl2sa8GcMFwIIpibpARTJRbwmHqKoYc9jcY5fr4e7dFjNMmA/0?wx_fmt=png" data-nickname="21ic電子網(wǎng)" data-alias="weixin21ic" data-signature="即時傳播最新電子科技信息，匯聚業(yè)界精英精彩視點。" data-from="0">