策略列舉:消除在專案裡大批量使用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話,著實是一件很影響效能的事情,雖然這點效能可忽略不計,但有更好的取代方案,不是更好嗎?
- 基於Gin Gorm框架搭建MVC模式的Go語言企業級後端系統
- 策略列舉:消除在專案裡大批量使用if-else的優雅姿勢
- 深入Spring Security魔幻山谷-獲取認證機制核心原理講解(新版)
- 實際使用Elasticdump工具對Elasticsearch叢集進行資料備份和資料還原
- Activiti工作流學習筆記(四)——工作流引擎中責任鏈模式的建立與應用原理
- 原創小說:孤島上住著一隻貓
- 策略列舉:消除在專案裡大批量使用if-else的正確姿勢
- visualvm工具遠端對linux伺服器上的JVM虛擬機器進行監控與調優
- Springboot2.x整合lettuce連線redis叢集報超時異常Command timed out after 6 second(s)
- Springboot專案啟動後自動建立多表關聯的資料庫與表的方案
- Activiti工作流學習筆記(三)——自動生成28張資料庫表的底層原理分析
- 前端筆記:React的form表單全部置空或者某個操作框置空的做法
- mybatis-plus的insert方法出現-id' doesn't have a default value問題