觀點一（靈劍）：

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

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

1. 提前 return

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

if(condition){
//dosomething
}else{
returnxxx;
}

其實，每次看到上面這種代碼，我都心里抓癢，完全可以先判斷!condition，干掉 else。

if(!condition){
returnxxx;

}
//dosomething

2. 策略模式

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

if(strategy.equals("fast")){
//快速執行
}elseif(strategy.equals("normal")){
//正常執行
}elseif(strategy.equals("smooth")){
//平滑執行
}elseif(strategy.equals("slow")){
//慢慢執行
}

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

2.1 多態

interfaceStrategy{
voidrun()throwsException;
}

classFastStrategyimplementsStrategy{
@Override
voidrun()throwsException{
//快速執行邏輯
}
}

classNormalStrategyimplementsStrategy{
@Override
voidrun()throwsException{
//正常執行邏輯
}
}

classSmoothStrategyimplementsStrategy{
@Override
voidrun()throwsException{
//平滑執行邏輯
}
}

classSlowStrategyimplementsStrategy{
@Override
voidrun()throwsException{
//慢速執行邏輯
}
}

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

Strategystrategy=map.get(param);
strategy.run();

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

2.2 枚舉

發現很多同學不知道在枚舉中可以定義方法，這里定義一個表示狀態的枚舉，另外可以實現一個run方法。

publicenumStatus{
NEW(0){
@Override
voidrun(){
//dosomething
}
},
RUNNABLE(1){
@Override
voidrun(){
//dosomething
}
};

publicintstatusCode;

abstractvoidrun();

Status(intstatusCode){
this.statusCode=statusCode;
}
}

重新定義策略枚舉

publicenumStrategy{
FAST{
@Override
voidrun(){
//dosomething
}
},
NORMAL{
@Override
voidrun(){
//dosomething
}
},

SMOOTH{
@Override
voidrun(){
//dosomething
}
},

SLOW{
@Override
voidrun(){
//dosomething
}
};
abstractvoidrun();
}

通過枚舉優化之后的代碼如下

Strategystrategy=Strategy.valueOf(param);
strategy.run();

3. 學會使用 Optional

Optional主要用于非空判斷，由于是jdk8新特性，所以使用的不是特別多，但是用起來真的爽。 使用之前：

if(user==null){
//doaction1
}else{
//doaction2
}

如果登錄用戶為空，執行action1，否則執行action 2，使用Optional優化之后，讓非空校驗更加優雅，間接的減少if操作

OptionaluserOptional=Optional.ofNullable(user);
userOptional.map(action1).orElse(action2);

4. 數組小技巧

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

intgetDays(intmonth){
if(month==1)return31;
if(month==2)return29;
if(month==3)return31;
if(month==4)return30;
if(month==5)return31;
if(month==6)return30;
if(month==7)return31;
if(month==8)return31;
if(month==9)return30;
if(month==10)return31;
if(month==11)return30;
if(month==12)return31;
}

優化后的代碼

intmonthDays[12]={31,29,31,30,31,30,31,31,30,31,30,31};
intgetDays(intmonth){
returnmonthDays[--month];
}

結束

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

觀點二（IT技術控）：

不要去過度關注 if/else 的層數，而要關注接口語義是否足夠清晰；單純減少if/else的層數，然后拆出一堆do_logic1, do_logic2…這樣的接口是毫無幫助的。

任何一個接口的執行過程都可以表示為：輸入 + 內部狀態 -> 輸出這樣的形式，我們分以下幾種情況來討論： 輸入、內部狀態、輸出都很簡單，但中間邏輯復雜。

比如說一個精心優化過的數值計算程序，可能需要根據輸入在不同的取值范圍采取不同的策略，還有很多邏輯用來處理會引發問題（比如除0）的邊界值，這種情況下 if/else 數量多是難以避免的。

根據步驟拆分出一些內部方法有一定幫助，但也不能完全解決問題。

這種情況下最好的做法是寫一篇詳細的文檔，從最原始的數學模型開始，然后表明什么情況下采取什么樣的計算策略，策略如何推導，知道得到代碼中使用的具體形式，然后給整個方法加上注釋附上文檔地址，并且在每個分支的地方加上注釋指明對應到文檔中哪個公式。

這種情況下雖然方法很復雜，但是語義是清晰的，如果不修改實現的話理解語義就行了，如果要修改實現那么需要參考對照文檔中的公式。

輸入過于復雜，比如輸入帶有一堆不同的參數，或者有各種奇怪的flag，每個flag有不同作用。 這種情況下首先需要提高接口的抽象層次：如果接口有多個不同作用，需要拆分成不同接口；如果接口內部根據不同參數進不同分支，需要將這些參數和對應分支包在Adapter里，使用參數的地方改寫成Adapter的接口，根據傳入的Adapter類型不同進入不同的實現；如果接口內部有復雜的參數轉換關系，需要改寫成查找表。

這種情況下的主要問題是接口本身抽象的有問題，有更清晰的抽象之后，實現也自然沒有那么多if/else了。 輸出過于復雜，為了省事一個過程計算出了太多東西，又為了性能加了一堆flag控制是否計算之類。這種情況下需要果斷將方法拆分成多個不同方法，每個方法只返回自己需要的內容。

如果不同計算之間有共用的內部結果呢？如果這個內部結果計算并不形成瓶頸，只要提取出內部方法然后在不同過程中分別調用即可；如果希望避免重復計算，可以增加一個額外的 cache 對象作為參數，cache內容對用戶不透明，用戶只保證相同輸入使用同一個cache對象即可，在計算中將中間結果保存到cache中，下次計算前先檢查有沒有已經得到的結果，就可以避免重復計算了。

內部狀態過于復雜。首先檢查狀態設置的是否合理，是不是有一些本來應該作為輸入參數的東西被放到了內部狀態中（比如用來隱式地在兩個不同方法調用之間傳遞參數）？ 其次，這些狀態分別控制哪些方面，是否可以分組然后實現到不同的 StateManager里面？ 第三，畫出狀態轉移圖，嘗試將內部狀態分成單層分支，然后分別實現到on_xxx_stat e這樣的方法里面，然后通過單層的 switch 或者查找表來調用。

其實通常需要優化的都是整體接口抽象，而不是單個接口的實現，單個接口實現不清晰通常是因為接口實現和需求不同構造成的。

審核編輯：劉清