【設計模式】告別冗長if-else語句：使用策略模式優化代碼結構
概述
先看下面的圖片，我們去旅游選擇出行模式有很多種，可以騎自行車、可以坐汽車、可以坐火車、可以坐飛機。
作為一個程序猿，開發需要選擇一款開發工具，當然可以進行代碼開發的工具有很多，可以選擇Idea進行開發，也可以使用eclipse進行開發，也可以使用其他的一些開發工具。
定義：該模式定義了一系列算法，并將每個算法封裝起來，使它們可以相互替換，且算法的變化不會影響使用算法的客戶。策略模式屬于對象行為模式，它通過對算法進行封裝，把使用算法的責任和算法的實現分割開來，并委派給不同的對象對這些算法進行管理。
結構
策略模式的主要角色如下：
-
抽象策略（Strategy）類：這是一個抽象角色，通常由一個接口或抽象類實現。此角色給出所有的具體策略類所需的接口。
-
具體策略（Concrete Strategy）類：實現了抽象策略定義的接口，提供具體的算法實現或行為。
-
環境（Context）類：持有一個策略類的引用，最終給客戶端調用。
案例實現
【例】促銷活動
一家百貨公司在定年度的促銷活動。針對不同的節日（春節、中秋節、圣誕節）推出不同的促銷活動，由促銷員將促銷活動展示給客戶。類圖如下：
代碼如下：
定義百貨公司所有促銷活動的共同接口
public interface Strategy {
void show();
}
定義具體策略角色（Concrete Strategy）：每個節日具體的促銷活動
//為春節準備的促銷活動A
public class StrategyA implements Strategy {
public void show() {
System.out.println("買一送一");
}
}
//為中秋準備的促銷活動B
public class StrategyB implements Strategy {
public void show() {
System.out.println("滿200元減50元");
}
}
//為圣誕準備的促銷活動C
public class StrategyC implements Strategy {
public void show() {
System.out.println("滿1000元加一元換購任意200元以下商品");
}
}
定義環境角色（Context）：用于連接上下文，即把促銷活動推銷給客戶，這里可以理解為銷售員
public class SalesMan {
//持有抽象策略角色的引用
private Strategy strategy;
public SalesMan(Strategy strategy) {
this.strategy = strategy;
}
//向客戶展示促銷活動
public void salesManShow(){
strategy.show();
}
}
優缺點
優點：
-
策略類之間可以自由切換：由于策略類都實現同一個接口，所以使它們之間可以自由切換。
-
易于擴展：增加一個新的策略只需要添加一個具體的策略類即可，基本不需要改變原有的代碼，符合“開閉原則“
-
避免使用多重條件選擇語句（if else），充分體現面向對象設計思想。
缺點：
-
客戶端必須知道所有的策略類，并自行決定使用哪一個策略類。
-
策略模式將造成產生很多策略類，可以通過使用享元模式在一定程度上減少對象的數量。
使用場景
-
一個系統需要動態地在幾種算法中選擇一種時，可將每個算法封裝到策略類中。
-
一個類定義了多種行為，并且這些行為在這個類的操作中以多個條件語句的形式出現，可將每個條件分支移入它們各自的策略類中以代替這些條件語句。
-
系統中各算法彼此完全獨立，且要求對客戶隱藏具體算法的實現細節時。
-
系統要求使用算法的客戶不應該知道其操作的數據時，可使用策略模式來隱藏與算法相關的數據結構。
-
多個類只區別在表現行為不同，可以使用策略模式，在運行時動態選擇具體要執行的行為。
源碼解析 - Comparator
Comparator 中的策略模式。在Arrays類中有一個 sort() 方法，如下：
public class Arrays{
public static <T> void sort(T[] a, Comparator<? super T> c) {
if (c == null) {
sort(a);
} else {
if (LegacyMergeSort.userRequested)
legacyMergeSort(a, c);
else
TimSort.sort(a, 0, a.length, c, null, 0, 0);
}
}
}
Arrays就是一個環境角色類，這個sort方法可以傳一個新策略讓Arrays根據這個策略來進行排序。就比如下面的測試類。
public class demo {
public static void main(String[] args) {
Integer[] data = {12, 2, 3, 2, 4, 5, 1};
// 實現降序排序
Arrays.sort(data, new Comparator<Integer>() {
public int compare(Integer o1, Integer o2) {
return o2 - o1;
}
});
System.out.println(Arrays.toString(data)); //[12, 5, 4, 3, 2, 2, 1]
}
}
這里我們在調用Arrays的sort方法時，第二個參數傳遞的是Comparator接口的子實現類對象。所以Comparator充當的是抽象策略角色，而具體的子實現類充當的是具體策略角色。環境角色類（Arrays）應該持有抽象策略的引用來調用。那么，Arrays類的sort方法到底有沒有使用Comparator子實現類中的 compare() 方法嗎？讓我們繼續查看TimSort類的 sort() 方法，代碼如下：
class TimSort<T> {
static <T> void sort(T[] a, int lo, int hi, Comparator<? super T> c,
T[] work, int workBase, int workLen) {
assert c != null && a != null && lo >= 0 && lo <= hi && hi <= a.length;
int nRemaining = hi - lo;
if (nRemaining < 2)
return; // Arrays of size 0 and 1 are always sorted
// If array is small, do a "mini-TimSort" with no merges
if (nRemaining < MIN_MERGE) {
int initRunLen = countRunAndMakeAscending(a, lo, hi, c);
binarySort(a, lo, hi, lo + initRunLen, c);
return;
}
...
}
private static <T> int countRunAndMakeAscending(T[] a, int lo, int hi,Comparator<? super T> c) {
assert lo < hi;
int runHi = lo + 1;
if (runHi == hi)
return 1;
// Find end of run, and reverse range if descending
if (c.compare(a[runHi++], a[lo]) < 0) { // Descending
while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) < 0)
runHi++;
reverseRange(a, lo, runHi);
} else { // Ascending
while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) >= 0)
runHi++;
}
return runHi - lo;
}
}
上面的代碼中最終會跑到 countRunAndMakeAscending() 這個方法中。我們可以看見，只用了compare方法，所以在調用Arrays.sort方法只傳具體compare重寫方法的類對象就行，這也是Comparator接口中必須要子類實現的一個方法。
策略枚舉替換大量的if-else語句
若遇到大量流程判斷語句，幾乎滿屏都是if-else語句，其實if-else是一種面向過程的實現。那么，如何避免在面向對象編程里大量使用if-else呢？
網絡上有很多解決思路，有工廠模式、策略模式、甚至是規則引擎，但這些使用起來還是過于繁重了。雖說避免出現過多的if-else，但是，卻會增加很多額外的類。
假如有這樣一個需求，需實現一周七天內分別知道要做事情的備忘功能，這里面就會涉及到一個流程判斷，你可能會立馬想到用if-else，那么，可能是會這樣實現
//if-else形式判斷
public String getToDo(String day){
if("Monday".equals(day)){
//......省略復雜語句
return "今天上英語課";
}else if("Tuesday".equals(day)){
//.....省略復雜語句
return "今天上語文課";
}else if("Wednesday".equals(day)){
//......省略復雜語句
return "今天上數學課";
}else if("Thursday".equals(day)){
//......省略復雜語句
return "今天上音樂課";
}else if("sunday".equals(day)){
//......省略復雜語句
return "今天上編程課";
}else{
//此處省略10086行......
}
}
這種代碼，在業務邏輯里，少量還好，若是幾百個判斷呢，可能整塊業務邏輯里都是滿屏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 "今天上音樂課";
}
};
//定義了一個實現了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()即可。
往期推薦
本文來自在線網站：seven的菜鳥成長之路，作者：seven，轉載請注明原文鏈接：www.seven97.top
浙公網安備 33010602011771號