觀點一（靈劍）：

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

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

1. 提前return

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

if (condition) {
 // do something
} else {
  return xxx;
}

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

if (!condition) {
  return xxx;

} 
// do something
 

2. 策略模式

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

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

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

2.1 多型

interface Strategy {
  void run() throws
 
 Exception;
}

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

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

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

class SlowStrategy implements Strategy {
    @Override
    void run() throws Exception {
        // 慢速執行邏輯
    }
}

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

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

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

2.2 列舉

發現很多同學不知道在列舉中可以定義方法，這裡定義一個表示狀態的列舉，另外可以實現一個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();
}

通過列舉優化之後的程式碼如下

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

3. 學會使用 Optional

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

if (user == null) {
    //do action 1
} else {
    //do action2
}

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

Optional<User> userOptional = Optional.ofNullable(user);
userOptional.map(action1).orElse(action2);

4. 陣列小技巧

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

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;
}

優化後的程式碼

int monthDays[12] = {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
int getDays(int month){
    return monthDays[--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_state這樣的方法裡面，然後通過單層的switch或者查詢表來呼叫。其實通常需要優化的都是整體介面抽象，而不是單個介面的實現，單個介面實現不清晰通常是因為介面實現和需求不同構造成的。