先貼個阿里的《 Java 開發手冊》中的一個規範
我們先不探討其他方式，主要講策略模式。
定義
策略模式（Strategy Design Pattern）：封裝可以互換的行爲，並使用委託來決定要使用哪一個。
策略模式是一種行爲設計模式， 它能讓你定義一系列算法， 並將每種算法分別放入獨立的類中， 以使算法的對象能夠相互替換。
用人話翻譯後就是：運行時我給你這個類的方法傳不同的 “key”，你這個方法就去執行不同的業務邏輯。
你品，你細品，這不就是 if else 乾的事嗎？
先直觀的看下傳統的多重 if else 代碼
public String getCheckResult(String type) {
if ("校驗1".equals(type)) {
return "執行業務邏輯1";
} else if ("校驗2".equals(type)) {
return "執行業務邏輯2";
} else if ("校驗3".equals(type)) {
return "執行業務邏輯3";
} else if ("校驗4".equals(type)) {
return "執行業務邏輯4";
} else if ("校驗5".equals(type)) {
return "執行業務邏輯5";
} else if ("校驗6".equals(type)) {
return "執行業務邏輯6";
} else if ("校驗7".equals(type)) {
return "執行業務邏輯7";
} else if ("校驗8".equals(type)) {
return "執行業務邏輯8";
} else if ("校驗9".equals(type)) {
return "執行業務邏輯9";
}
return "不在處理的邏輯中返回業務錯誤";
}
這麼看，你要是還覺得挺清晰的話，想象下這些 return 裏是各種複雜的業務邏輯方法~~
當然，策略模式的作用可不止是避免冗長的 if-else 或者 switch 分支，它還可以像模板方法模式那樣提供框架的擴展點等。
網上的示例很多，比如不同路線的規劃、不同支付方式的選擇 都是典型的 if-else 問題，也都是典型的策略模式問題，栗子我們待會看，先看下策略模式的類圖，然後去改造多重判斷~
類圖
策略模式涉及到三個角色：
- Strategy：策略接口或者策略抽象類，用來約束一系列的策略算法（Context 使用這個接口來調用具體的策略實現算法）
- ConcreateStrategy：具體的策略類（實現策略接口或繼承抽象策略類）
- Context：上下文類，持有具體策略類的實例，並負責調用相關的算法
應用策略模式來解決問題的思路
實例
先看看最簡單的策略模式 demo:
1、策略接口（定義策略）
public interface Strategy {
void operate();
}
2、具體的算法實現
public class ConcreteStrategyA implements Strategy {
@Override
public void operate() {
//具體的算法實現
System.out.println("執行業務邏輯A");
}
}
public class ConcreteStrategyB implements Strategy {
@Override
public void operate() {
//具體的算法實現
System.out.println("執行業務邏輯B");
}
}
3、上下文的實現
public class Context {
//持有一個具體的策略對象
private Strategy strategy;
//構造方法，傳入具體的策略對象
public Context(Strategy strategy){
this.strategy = strategy;
}
public void doSomething(){
//調用具體的策略對象進操作
strategy.operate();
}
}
4、客戶端使用（策略的使用）
public static void main(String[] args) {
Context context = new Context(new ConcreteStrategyA());
context.doSomething();
}
ps：這種策略的使用方式其實很死板，真正使用的時候如果還這麼寫，和寫一大推 if-else 沒什麼區別，所以我們一般會結合工廠類，在運行時動態確定使用哪種策略。策略模式側重如何選擇策略、工廠模式側重如何創建策略。
解析策略模式
策略模式的功能就是把具體的算法實現從具體的業務處理中獨立出來，把它們實現成單獨的算法類，從而形成一系列算法，並讓這些算法可以互相替換。
策略模式的重心不是如何來實現算法，而是如何組織、調用這些算法，從而讓程序結構更靈活，具有更好的維護性和擴展性。
實際上，每個策略算法具體實現的功能，就是原來在 if-else 結構中的具體實現，每個 if-else語句都是一個平等的功能結構，可以說是兄弟關係。
策略模式呢，就是把各個平等的具體實現封裝到單獨的策略實現類了，然後通過上下文與具體的策略類進行交互。
『 策略模式 = 實現策略接口（或抽象類）的每個策略類 + 上下文的邏輯分派 』
策略模式的本質：分離算法，選擇實現 ——《研磨設計模式》
所以說，策略模式只是在代碼結構上的一個調整，即使用了策略模式，該寫的邏輯一個也少不了，到邏輯分派的時候，只是變相的 if-else。
而它的優化點是抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if-else 更好維護和擴展些。
誰來選擇具體的策略算法
如果你手寫了上邊的 demo，就會發現，這玩意不及 if-else 來的順手，尤其是在判斷邏輯的時候，每個邏輯都要要構造一個上下文對象，費勁。
其實，策略模式中，我們可以自己定義誰來選擇具體的策略算法，有兩種：
- 客戶端：當使用上下文時，由客戶端選擇，像我們上邊的 demo
- 上下文：客戶端不用選，由上下文來選具體的策略算法，可以在構造器中指定
優缺點
優點：
- 避免多重條件語句：也就是避免大量的 if-else
- 更好的擴展性（完全符合開閉原則）：策略模式中擴展新的策略實現很容易，無需對上下文修改，只增加新的策略實現類就可以
缺點：
- 客戶必須瞭解每種策略的不同（這個可以通過 IOC、依賴注入的方式解決）
- 增加了對象數：每個具體策略都封裝成了類，可能備選的策略會很多
- 只適合扁平的算法結構：策略模式的一系列算法是平等的，也就是在運行時刻只有一個算法會被使用，這就限制了算法使用的層級，不能嵌套使用
思考
實際使用中，往往不會只是單一的某個設計模式的套用，一般都會混合使用，而且模式之間的結合也是沒有定勢的，要具體問題具體分析。
策略模式往往會結合其他模式一起使用，比如工廠、模板等，具體使用需要結合自己的業務。
切記，不要爲了使用設計模式而強行模式，不要把簡單問題複雜化。
策略模式也不是專爲消除 if-else 而生的，不要和 if-else 劃等號。它體現了“對修改關閉，對擴展開放“的原則。
並不是說，看到 if-else 就想着用策略模式去優化，業務邏輯簡單，可能幾個枚舉，或者幾個衛語句就搞定的場景，就不用非得硬套設計模式了。
策略模式在 JDK 中的應用
在 JDK 中，Comparator 比較器是一個策略接口，我們常用的 compare() 方法就是一個具體的策略實現，用於定義排序規則。
public interface Comparator<T> {
int compare(T o1, T o2);
//......
}
當我們想自定義排序規則的時候，就可以實現 Comparator 。
這時候我們重寫了接口中的 compare() 方法，就是具體的策略類（只不過這裏可能是內部類）。當我們在調用 Arrays 的排序方法 sort() 時，可以用默認的排序規則，也可以用自定義的規則。
public static void main(String[] args) {
Integer[] data = {4,2,7,5,1,9};
Comparator<Integer> comparator = new Comparator<Integer>() {
@Override
public int compare(Integer o1, Integer o2) {
if(o1 > o2){
return 1;
} else {
return -1;
}
}
};
Arrays.sort(data,comparator);
System.out.println(Arrays.toString(data));
}
Arrays 的 sort() 方法，有自定義規則就按自己的方法排序，反之走源碼邏輯。
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);
}
}
還有，ThreadPoolExecutor 中的拒絕策略 RejectedExecutionHandler 也是典型的策略模式，感興趣的也可以再看看源碼。