策略列舉：消除在專案裡大批量使用if-else的優雅姿勢_朱季謙

文/朱季謙

想起剛開始接觸JAVA面向物件程式設計時，若遇到大量流程判斷語句，幾乎滿屏都是if-else語句，多得讓自己都忘了哪裡是頭，哪裡是尾，但是，縱然滿屏是if-else，但彼時也沒有覺得多彆扭。等到程式設計能力漸漸提升之後，再回過頭去看曾經寫過的滿屏if-else時，腦海裡只有一個畫面，全都是翔.....

可能初學者都會忽略掉一點，其實if-else是一種面向過程的實現。

那麼，如何避免在面向物件程式設計裡大量使用if-else呢？

網路上有很多解決思路，有工廠模式、策略模式、甚至是規則引擎（這個太重了吧）......

這些，都有一個共同的缺點，使用起來還是過於繁重了。雖說避免出現過多的if-else，但是，卻會增加很多額外的類，我總覺得，很不實用，只能當做某種模式的學習即可。

可以替換大量的if-else語句，且具備較好的可讀性與擴充套件性，同時能顯得輕量化，我比較推薦使用策略列舉來消除if-else。

如何使用呢，下面先從一個業務案例開始說起下——

假如有這樣一個需求，需實現一週七天內分別知道要做事情的備忘功能，這裡面就會涉及到一個流程判斷，你可能會立馬想到用if-else，那麼，可能是會這樣實現——

1 //if-else形式判斷 2 public String getToDo(String day){ 3 if("Monday".equals(day)){ ......省略複雜語句 4 return "今天上英語課"; 5 }else if("Tuesday".equals(day)){ .....省略複雜語句 return "今天上語文課"; 7 }else if("Wednesday".equals(day)){ ......省略複雜語句 8 return "今天上數學課"; 9 }else if("Thursday".equals(day)){ ......省略複雜語句 10 return "今天上音樂課"; 11 }else if("sunday".equals(day)){ ......省略複雜語句 12 return "今天上程式設計課"; 13 }else{ 14 此處省略10086行...... 15 } 16 }

這種程式碼，在業務邏輯裡，少量還好，若是幾百個判斷呢，可能整塊業務邏輯裡都是滿屏if-else,既不優雅也顯得很少冗餘。

這時，就可以考慮使用策略列舉形式來替換這堆面向過程的if-else實現了。

首先，先定義一個getToDo()呼叫方法，假如傳進的是“星期一”，即引數"Monday"。

//策略列舉判斷 public String getToDo(String day){ CheckDay checkDay=new CheckDay(); return checkDay.day(DayEnum.valueOf(day)); }

在getToDo()方法裡，通過DayEnum.valueOf("Monday")可獲取到一個DayEnum列舉元素，這裡得到的是Monday。

接下來，執行checkDay.day(DayEnum.valueOf("Monday"))，會進入到day（）方法中，這裡，通過dayEnum.toDo()做了一個策略匹配時。注意一點，DayEnum.valueOf("Monday")得到的是列舉中的Monday，這樣，實質上就是執行了Monday.toDo()，也就是說，會執行Monday裡的toDo()——

public class CheckDay { public String day( DayEnum dayEnum) { return dayEnum.toDo(); } }

上面的執行過程為什麼會是這樣子呢？只有進入到DayEnum列舉當中，才知道是怎麼回事了——(話外音：我第一次接觸策略模式時，猛地一驚，原來列舉還可以這樣玩)

public enum DayEnum { Monday { @Override public String toDo() { ......省略複雜語句 return "今天上英語課"; } }, Tuesday { @Override public String toDo() { ......省略複雜語句 return "今天上語文課"; } }, Wednesday { @Override public String toDo() { ......省略複雜語句 return "今天上數學課"; } }, Thursday { @Override public String toDo() { ......省略複雜語句 return "今天上音樂課"; } }; public abstract String toDo(); }

在DayEnum列舉屬性當中，定義了一個實現了toDo()抽象方法——

public abstract String toDo();

在每個列舉元素當中，都重寫了該toDo()抽象方法。這樣，當傳參DayEnum.valueOf("Monday")流轉到dayEnum.toDo()時，實質上是去DayEnum列舉裡找到對應Monday定義的列舉元素，然後執行其內部重寫的toDo()方法。用if-esle形式表示，就類似"Monday".equals(day)匹配為true時，可得到其內部東西。

總結一下，策略列舉就是列舉當中使用了策略模式，所謂的策略模式，即給你一把鑰匙，按照某種約定的方式，可以立馬被指引找到可以開啟的門。例如，我給你的鑰匙叫“Monday”，那麼，就可以通過約定方式dayEnum.toDo()，立馬找到列舉裡的Monday大門，然後進到門裡，去做想做的事toDo()，其中，每扇門後的房間都有不同的功能，但它們都有一個相同抽象功能——toDo()，即各房間共同地方都是可以用來做一些事情的功能，但具體可以什麼事情，就各有不同了。在本文的案例裡，每扇大門裡的toDo()，根據不同策略模式可得到不同字串返回，例如，"今天上英語課"、"今天上語文課"，等等。

可見，把流程判斷抽取到策略列舉當中，還可以把一堆判斷解耦出來，避免在業務程式碼邏輯裡呈現一大片密密麻麻冗餘的if-else。

這裡，會出現一種情況，即，假如有多個重複共同樣功能的判斷話，例如，在if-else裡，是這樣——

public String getToDoByIfElse(String day){ if("Monday".equals(day)||"Tuesday".equals(day)||"Wednesday".equals(day)){ ......省略複雜語句 return "今天上英語課"; }else if("Thursday".equals(day)){ ...... } }

那麼，在策略列舉下應該如何使用從而避免程式碼冗餘呢？

可以參考一下以下思路，設定一個內部策略列舉，將有相同功能的外部引用指向同一個內部列舉元素，這樣即可實現呼叫重複功能了——

``` public enum DayEnum { //指向內部列舉的同一個屬性即可執行相同重複功能 Monday("星期一", Type.ENGLISH), Tuesday("星期二", Type.ENGLISH), Wednesday("星期三", Type.ENGLISH),

Thursday("星期四", Type.CHINESE);
private final Type type;
private final String day;
DayEnum(String day, Type type) {
    this.day = day;
    this.type = type;
}
String toDo() {
    return type.toDo();
}
/**
 * 內部策略列舉
 */
private enum Type {
    ENGLISH {
        @Override
        public String toDo() {
            ......省略複雜語句
            return "今天上英語課";
        }
    },
    CHINESE {
        @Override
        public String toDo() {
            ......省略複雜語句
            return "今天上語文課";
        }
    };
    public abstract String toDo();
}

} ```

若要擴充套件其判斷流程，只需要直接在列舉增加一個屬性和內部toDo（實現），就可以增加新的判斷流程了，而外部，仍舊用同一個入口dayEnum.toDo()即可。

可能，會有這樣一個疑問：為什麼在列舉裡定義一個抽象方法，會在各個列舉元素裡實現呢？

這功能就類似子類繼承父類的做法了。DayEnum類似一個父類，DayEnum列舉裡的元素就相當是其子類。當父類裡定義了抽象方法toDo（），其繼承的子類就會預設實現toDo()方法，這樣，就會出現列舉裡可以這樣的寫法：

private enum Type { ENGLISH { @Override public String toDo() { return "今天上英語課"; } }； public abstract String toDo(); }

我很喜歡在大批量if-else裡使用策略列舉來消除替換，總而言之，使用策略列舉可以很靈活處理各種複雜判斷，且可讀性與擴充套件性都比較好，它更像是函數語言程式設計，即傳進一個引數，就可以得到對應模式下返回的數值。

若Java裡業務邏輯中大批量使用if-else，則是面向過程了，因為業務邏輯裡的if-else是從上往下一個if接一個if判斷下去的，在各個if上打個斷點，debug下去，就明白它其實是面向過程的。

由此可知，若專案裡有大量的if-else話，著實是一件很影響效能的事情，雖然這點效能可忽略不計，但有更好的取代方案，不是更好嗎？