消滅 if / else

      

       

       


       

        前期迭代懶得優(yōu)化，來一個(gè)需求，加一個(gè)if，久而久之，就堆成了一座山。
       
       

        

       
       

       

        

當(dāng)代碼已經(jīng)復(fù)雜到難以維護(hù)的程度之后，只能狠下心重構(gòu)優(yōu)化。
        

         那，有什么方案可以優(yōu)雅的優(yōu)化掉這些多余的 if/else ?
        
        

         觀點(diǎn)一：消滅if/else
        
        
1-提前 return
        

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

          

           

           

           

           

           

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

          其實(shí)，每次看到上面這種代碼，我都心里抓癢。
         
         

          完全可以先判斷!condition，干掉 else。
         
        
         

          

           

           

           

           

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

          2-策略模式
         
        

         有這么一種場景，根據(jù)不同的參數(shù)走不同的邏輯，其實(shí)這種場景很常見。
        
        

         最一般的實(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 {@Overridevoid run() throws Exception     {// 快速執(zhí)行邏輯    }}
class NormalStrategy implements Strategy {@Overridevoid run() throws Exception     {// 正常執(zhí)行邏輯    }}
class SmoothStrategy implements Strategy {@Overridevoid run() throws Exception     {// 平滑執(zhí)行邏輯    }}
class SlowStrategy implements Strategy {@Overridevoid run() throws Exception     {// 慢速執(zhí)行邏輯    }}
         
         

          
         
        
         

          具體策略對(duì)象存放在一個(gè)Map中，優(yōu)化后的實(shí)現(xiàn)：

         
         

          

           

           

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

          
         
         

          上面這種優(yōu)化方案有一個(gè)弊端。
          

         
        
         

          為了能夠快速拿到對(duì)應(yīng)的策略實(shí)現(xiàn)，需要map對(duì)象來保存策略。
         
         

          當(dāng)添加一個(gè)新策略的時(shí)候，還需要手動(dòng)添加到map中，容易被忽略。
         
         

          2.2 枚舉
         
        

         發(fā)現(xiàn)很多同學(xué)不知道在枚舉中可以定義方法。
        
        

         這里定義一個(gè)表示狀態(tài)的枚舉，另外可以實(shí)現(xiàn)一個(gè)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 {@Overridevoid run() {//do something        }    },    NORMAL {@Overridevoid run() {//do something        }    },
    SMOOTH {@Overridevoid run() {//do something        }    },
    SLOW {@Overridevoid run() {//do something        }    };abstract void run();}
         
         

          
         
         

          通過枚舉優(yōu)化之后的代碼如下:
         
         

          

           

           

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

          
         
        
         

          3-學(xué)會(huì)使用 Optional

         
        

         Optional主要用于非空判斷，由于是jdk8新特性，所以使用的不是特別多。
        
        

         但是用起來真的爽，使用之前：
        
        

         

          

          

          

          

          

          

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

         
        
        
         

          如果登錄用戶為空，執(zhí)行action1，否則執(zhí)行action 2。
         
         

          使用Optional優(yōu)化之后，讓非空校驗(yàn)更加優(yōu)雅，間接的減少if操作：
         
         

          

           

           

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

          
         
        
         

          4-數(shù)組小技巧
         
         

          來自google解釋，這是一種編程模式，叫做表驅(qū)動(dòng)法。
         
         

          本質(zhì)是從表里查詢信息來代替邏輯語句。
         
         

          比如有這么一個(gè)場景：
         
         

          通過月份來獲取當(dāng)月的天數(shù)，僅作為案例演示，數(shù)據(jù)并不嚴(yán)謹(jǐn)。
         
         

          一般的實(shí)現(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];}
         
         

          
         
        
         

          if else 作為每種編程語言都不可或缺的條件語句，在編程時(shí)會(huì)大量的用到。

         
        

         一般建議嵌套不要超過三層。
        
        

         如果一段代碼存在過多的if else嵌套，代碼的可讀性就會(huì)急速下降。
        
        

         后期維護(hù)難度也大大提高。
        
        

         觀點(diǎn)二：讓語義清晰
        
        

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

         任何一個(gè)接口的執(zhí)行過程都可以表示為：輸入 + 內(nèi)部狀態(tài) -> 輸出這樣的形式，我們分以下幾種情況來討論：
        
        

         輸入、內(nèi)部狀態(tài)、輸出都很簡單，但中間邏輯復(fù)雜。比如說一個(gè)精心優(yōu)化過的數(shù)值計(jì)算程序，可能需要根據(jù)輸入在不同的取值范圍采取不同的策略，還有很多邏輯用來處理會(huì)引發(fā)問題（比如除0）的邊界值，這種情況下 if/else 數(shù)量多是難以避免的。
        
        

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

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

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

         輸入過于復(fù)雜，比如輸入帶有一堆不同的參數(shù)，或者有各種奇怪的flag，每個(gè)flag有不同作用。
        
        

         這種情況下首先需要提高接口的抽象層次：如果接口有多個(gè)不同作用，需要拆分成不同接口；如果接口內(nèi)部根據(jù)不同參數(shù)進(jìn)不同分支，需要將這些參數(shù)和對(duì)應(yīng)分支包在Adapter里，使用參數(shù)的地方改寫成Adapter的接口，根據(jù)傳入的Adapter類型不同進(jìn)入不同的實(shí)現(xiàn)；如果接口內(nèi)部有復(fù)雜的參數(shù)轉(zhuǎn)換關(guān)系，需要改寫成查找表。
        
        

         這種情況下的主要問題是接口本身抽象的有問題，有更清晰的抽象之后，實(shí)現(xiàn)也自然沒有那么多if/else了。
        
        

         輸出過于復(fù)雜，為了省事一個(gè)過程計(jì)算出了太多東西，又為了性能加了一堆flag控制是否計(jì)算之類。這種情況下需要果斷將方法拆分成多個(gè)不同方法，每個(gè)方法只返回自己需要的內(nèi)容。
        
        

         如果不同計(jì)算之間有共用的內(nèi)部結(jié)果呢？如果這個(gè)內(nèi)部結(jié)果計(jì)算并不形成瓶頸，只要提取出內(nèi)部方法然后在不同過程中分別調(diào)用即可；如果希望避免重復(fù)計(jì)算，可以增加一個(gè)額外的 cache 對(duì)象作為參數(shù)，cache內(nèi)容對(duì)用戶不透明，
        
        

         用戶只保證相同輸入使用同一個(gè)cache對(duì)象即可，在計(jì)算中將中間結(jié)果保存到cache中，下次計(jì)算前先檢查有沒有已經(jīng)得到的結(jié)果，就可以避免重復(fù)計(jì)算了。
         

        
        

         內(nèi)部狀態(tài)過于復(fù)雜。首先檢查狀態(tài)設(shè)置的是否合理，是不是有一些本來應(yīng)該作為輸入?yún)?shù)的東西被放到了內(nèi)部狀態(tài)中，比如用來隱式地在兩個(gè)不同方法調(diào)用之間傳遞參數(shù)？
        
        

         其次，這些狀態(tài)分別控制哪些方面，是否可以分組然后實(shí)現(xiàn)到不同的 StateManager里面？
        
        

         第三，畫出狀態(tài)轉(zhuǎn)移圖，嘗試將內(nèi)部狀態(tài)分成單層分支，然后分別實(shí)現(xiàn)到on_xxx_stat e這樣的方法里面，然后通過單層的 switch 或者查找表來調(diào)用。
        
        

         其實(shí)通常需要優(yōu)化的都是整體接口抽象，而不是單個(gè)接口的實(shí)現(xiàn)，單個(gè)接口實(shí)現(xiàn)不清晰通常是因?yàn)榻涌趯?shí)現(xiàn)和需求不同構(gòu)造成的。
        
        

         原文：https://www.zhihu.com/question/344856665/answer/816270460
        
       
       

        

         版權(quán)聲明：本文來源網(wǎng)絡(luò)，免費(fèi)傳達(dá)知識(shí)，版權(quán)歸原作者所有。如涉及作品版權(quán)問題，請(qǐng)聯(lián)系我進(jìn)行刪除。
        
        

        

         
        
       
       

        

         

          
????????????????  END  ???????????????