在理解策略模式之前我們假設有這樣一個需求場景：我們在寫訂單支付場景的代碼時，客戶可以選擇多種支付方式，有銀聯支付、支付寶支付、微信支付、京東白條等等。然后我們就很可能就會編寫出類似下面這樣的代碼：
/**
* 訂單類，擁有一個支付方法
*
* @author eamon.zhang
* @date 2019-11-06 上午9:18
*/
public class Order {
// 訂單id
private String orderId;
// 支付方式
private String payType;
// 訂單金額
private long amount;
public Order(String orderId, String payType, long amount) {
this.orderId = orderId;
this.payType = payType;
this.amount = amount;
}
/**
* 訂單支付方法
*
* @return
*/
public boolean pay() {
// 是否支付成功
boolean payment = false;
if ("aliPay".equals(payType)) {
System.out.println("用戶選擇 支付寶 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
payment = true;
} else if ("unionPay".equals(payType)) {
System.out.println("用戶選擇 銀聯 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
payment = true;
} else if ("jdPay".equals(payType)) {
System.out.println("用戶選擇 京東 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
payment = true;
} else if ("wechatPay".equals(payType)) {
System.out.println("用戶選擇 微信 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
payment = true;
}
return payment;
}
}
客戶端：
@Test
public void test() {
String orderId = "123";
String payType = "aliPay";
long amount = 200;
// 創建訂單
Order order = new Order(orderId, payType, amount);
// 支付
order.pay();
}
結果：
用戶選擇 支付寶 支付，訂單號為：123 ，支付金額：200
可以看出這段代碼在邏輯上沒有問題，也能夠很好的運行；
但是存在一個問題：將所有的支付方式都寫在同一個方法里面，顯得有點臃腫，還帶來了一個擴展的問題，如果我們再增加一種支付方式，我們就不得不修改這段代碼，再增加一條 if...else，這就降低了代碼的可維護性。違背了開閉原則。
那能否有一種方法能讓我們既不修改主要邏輯代碼的前提下讓代碼變得更優雅也能很好的對其進行擴展呢？那不防我們一起來看看今天的主角：策略模式
定義
策略模式屬於對象的行為模式。其用意是針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發生變化，也就是在策略模式（Strategy Pattern）中，一個類的行為或其算法可以在運行時更改。
結構
策略模式中一般會涉及到三個角色：
- 策略接口角色
IStrategy：用來約束一系列具體的策略算法，策略上下文角色ConcreteStrategy使用此策略接口來調用具體的策略所實現的算法。 - 具體策略實現角色
ConcreteStrategy：具體的策略實現，即具體的算法實現。 - 策略上下文角色
StrategyContext：策略上下文，負責和具體的策略實現交互，通常策略上下文對象會持有一個真正的策略實現對象，策略上下文還可以讓具體的策略實現從其中獲取相關數據，回調策略上下文對象的方法。
類圖結構：
簡單代碼實現
先創建抽象策略接口 IStrategy ：
/**
* 策略類抽象接口，具體策略實現由其子類來實現
*
* @author EamonZzz
* @date 2019-11-02 16:12
*/
public interface IStrategy {
/**
* 定義的抽象算法方法 來約束具體的算法實現方法
*/
void algorithmMethod();
}
創建具體的策略實現類 ConcreteStrategyA：
/**
* 策略具體實現類A
*
* @author EamonZzz
* @date 2019-11-02 16:48
*/
public class ConcreteStrategyA implements IStrategy {
/**
* 具體的算法體現
*/
@Override
public void algorithmMethod() {
System.out.println("this is ConcreteStrategyA method...");
}
}
創建具體的策略實現類 ConcreteStrategyB:
/**
* 策略具體實現類B
*
* @author EamonZzz
* @date 2019-11-02 16:48
*/
public class ConcreteStrategyB implements IStrategy {
/**
* 具體的算法體現
*/
@Override
public void algorithmMethod() {
System.out.println("this is ConcreteStrategyB method...");
}
}
創建具體的策略實現類 ConcreteStrategyC:
/**
* 策略具體實現類C
*
* @author EamonZzz
* @date 2019-11-02 16:48
*/
public class ConcreteStrategyC implements IStrategy {
/**
* 具體的算法體現
*/
@Override
public void algorithmMethod() {
System.out.println("this is ConcreteStrategyC method...");
}
}
創建策略上下文 StrategyContext ：
/**
* 策策略上下文，負責和具體的策略實現交互，通常策略上下文對象會持有一個真正的策略實現對象，
* 策略上下文還可以讓具體的策略實現從其中獲取相關數據，回調策略上下文對象的方法。
*
* @author EamonZzz
* @date 2019-11-02 16:11
*/
public class StrategyContext {
/**
* 策略實現的引用
*/
private IStrategy strategy;
/**
* 構造器注入具體的策略類
*
* @param iStrategy 策略實現的引用
*/
public StrategyContext(IStrategy iStrategy) {
this.strategy = iStrategy;
}
public void contextMethod() {
// 調用策略實現的方法
strategy.algorithmMethod();
}
}
最后編寫測試類來測試一下結果
/**
* @author EamonZzz
* @date 2019-11-02 16:53
*/
public class StrategyContextTest {
@Test
public void test(){
// 1. 創建具體的策略實現
IStrategy strategy = new ConcreteStrategyA();
// 2. 在創建策略上下文的同時，將具體的策略實現對象注入到策略上下文當中
StrategyContext ctx = new StrategyContext(strategy);
// 3. 調用上下文對象的方法來完成對具體策略實現的回調
ctx.contextMethod();
}
}
控制台輸出：
this is ConcreteStrategyA method...
改造
在簡單的了解了策略模式之后，再看看文章開頭的實例場景，我們使用策略模式來對其進行改造：
我們將訂單支付邏輯中的各種支付場景算法單獨抽離出來：
先創建抽象的支付接口 Payment ，讓各種平台的支付邏輯類都實現該接口，達到統一調用的目的：
/**
* 統一支付接口
*
* @author eamon.zhang
* @date 2019-11-06 上午9:44
*/
public interface Payment {
boolean pay(String orderId, long amount);
}
然后分別創建支付寶支付類 AliPay ：
/**
* 支付寶支付
*
* @author eamon.zhang
* @date 2019-11-06 上午9:48
*/
public class AliPay implements Payment {
@Override
public boolean pay(String orderId, long amount) {
System.out.println("用戶選擇 支付寶 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
return true;
}
}
創建微信支付類 WeChatPay ：
/**
* 微信支付
*
* @author eamon.zhang
* @date 2019-11-06 上午9:49
*/
public class WeChatPay implements Payment {
@Override
public boolean pay(String orderId, long amount) {
System.out.println("用戶選擇 微信 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
return true;
}
}
創建銀聯支付類 UnionPay ：
/**
* 銀聯支付
*
* @author eamon.zhang
* @date 2019-11-06 上午9:50
*/
public class UnionPay implements Payment {
@Override
public boolean pay(String orderId, long amount) {
System.out.println("用戶選擇 銀聯 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
return true;
}
}
然后創建訂單類 Order :
/**
* 訂單類，相當於 策略上下文角色
*
* @author eamon.zhang
* @date 2019-11-06 上午9:43
*/
public class Order {
// 訂單id
private String orderId;
// 金額
private long amount;
// 具體支付類型的引用
private Payment payType;
public Order(String orderId, Payment payType, long amount) {
this.orderId = orderId;
this.payType = payType;
this.amount = amount;
}
/**
* 訂單支付方法
*
* @return
*/
public boolean pay() {
boolean paySuccess;
// 調用支付接口
paySuccess = payType.pay(orderId, amount);
if (!paySuccess) {
// 支付失敗邏輯
System.out.println("支付失敗！");
}
return paySuccess;
}
}
最后創建我們的客戶端模擬調用：
@Test
public void test() {
// 創建支付策略
Payment weChatPay = new WeChatPay();
// 創建策略上下文（訂單），並將具體的策略實現注入
String orderId = "123456";
long amount = 150;
Order order = new Order(orderId, weChatPay, amount);
// 調用具體支付策略邏輯
order.pay();
}
運行結果：
用戶選擇 微信 支付，訂單號為：123456 ，支付金額：150
這樣就對訂單支付場景完成了一個基本的改造，訂單支付的選擇權直接在用戶選擇支付方式時創建，訂單支付方法中統一進行調用；當我們需要新增加一種支付方式時，就可以直接繼承 Payment 抽象支付策略接口，然后實現支付方法，比如我們現在增加了一種京東白條支付 JdPay 就可以這樣寫：
/**
* 京東支付
*
* @author eamon.zhang
* @date 2019-11-06 上午9:49
*/
public class JdPay implements Payment {
@Override
public boolean pay(String orderId, long amount) {
System.out.println("用戶選擇 京東 支付，訂單號為：" + orderId + " ，支付金額：" + amount);
return true;
}
}
同樣的在客戶端調用：
/**
* @author eamon.zhang
* @date 2019-11-06 上午10:00
*/
public class OrderTest {
@Test
public void test() {
// 創建支付策略
Payment jdPay = new JdPay();
// 創建策略上下文（訂單），並將具體的策略實現注入
String orderId = "123456";
long amount = 150;
Order order = new Order(orderId, jdPay, amount);
// 調用具體支付策略邏輯
order.pay();
}
}
運行結果：
用戶選擇 京東 支付，訂單號為：123456 ，支付金額：150
可以看到，在經過使用 策略模式 改造之后，我們的訂單支付的擴展變得非常的容易，增加支付方式時，直接創建一個類並實現支付邏輯即可，不需要再修改我們的主類 Order。這就遵循了 開閉原則 。
再改造
上面第一次改造，只能勉強說明 策略模式 給實際業務帶來的好處，但是回到我們現實的支付場景中，用戶選擇支付方式並且支付的操作都是在前端頁面進行的，而且現在大都使用 前后端分離 的模式來進行開發，並不能像 JSP 那樣，可以在頁面中創建 Java 對象，在前后端分離的場景中，所有參數都是從頁面構建好鍵值對傳入，其基本類型為數字、字符串等等。所以我們可以再結合之前說的 工廠模式 進行改造，使其更適合現實場景。
創建支付策略的工廠類 PayStrategyFactory ：
/**
* 創建支付策略的工廠類
*
* @author eamon.zhang
* @date 2019-11-06 上午10:32
*/
public class PayStrategyFactory {
// 支付方式常量
public static final String ALI_PAY = "aliPay";
public static final String JD_PAY = "jdPay";
public static final String WECHAT_PAY = "wechatPay";
public static final String UNION_PAY = "unionPay";
// 支付方式管理集合
private static Map<String, Payment> PAYMENT_STRATEGY_MAP = new HashMap<>();
static {
PAYMENT_STRATEGY_MAP.put(ALI_PAY, new AliPay());
PAYMENT_STRATEGY_MAP.put(JD_PAY, new JdPay());
PAYMENT_STRATEGY_MAP.put(WECHAT_PAY, new WeChatPay());
PAYMENT_STRATEGY_MAP.put(UNION_PAY, new UnionPay());
}
/**
* 獲取支付方式類
*
* @param payType 前端傳入支付方式
* @return
*/
public static Payment getPayment(String payType) {
Payment payment = PAYMENT_STRATEGY_MAP.get(payType);
if (payment == null) {
throw new NullPointerException("支付方式選擇錯誤！");
}
return payment;
}
}
然后結合實際情況對 Order 類進行修改，使其支付方式的選擇權交由用戶做支付動作時進行選擇，因為提交訂單后可以選擇不支付，這時候訂單可以先創建：
/**
* 訂單類，相當於 策略上下文角色
*
* @author eamon.zhang
* @date 2019-11-06 上午9:43
*/
public class Order {
// 訂單id
private String orderId;
// 金額
private long amount;
public Order(String orderId, long amount) {
this.orderId = orderId;
this.amount = amount;
}
/**
* 訂單支付方法
*
* @return
*/
public boolean pay(String payType) {
boolean paySuccess;
Payment payment = PayStrategyFactory.getPayment(payType);
// 調用支付接口
paySuccess = payment.pay(orderId, amount);
if (!paySuccess) {
// 支付失敗邏輯
System.out.println("支付失敗！");
}
return paySuccess;
}
}
最后創建測試代碼：
@Test
public void test() {
// 前端傳入的參數
String orderId = "01000005";
String payType = PayStrategyFactory.ALI_PAY;
long amount = 190;
// 創建策略上下文（訂單），並將具體的策略實現注入
Order order = new Order(orderId, amount);
// 實際情況是 在支付的時候選擇支付方式，因為有可能先提交了訂單，后面再付款
order.pay(payType);
}
測試結果：
用戶選擇 支付寶 支付，訂單號為：01000005 ，支付金額：190
這樣才算完成了一個比較友好且更貼合實際業務情況的業務代碼。當然這只是簡單的一個示例，現實中，代碼的邏輯會非常復雜；現實中各種設計模式通常我們會配合進行使用，策略模式的使用頻率也非常的高，希望大家看完之后能夠理解並運用。
總結
應用場景
- 假如系統中有很多類，而他們的區別僅僅只是他們之間的行為，那么使用策略模式可以動態地讓一個對象在許多行為中選擇一種行為
- 一個系統需要動態地在幾種算法中選擇一種
- 如果一個對象有很多的行為，如果不用恰當的模式，這些行為就只好使用多重的條件選擇語句來實現
常用來解決的問題
在有多種算法相似的情況下，解決使用 if...else 所帶來的復雜和難以維護的問題
在JDK中的體現
在 JDK 源碼中也有非常多的 策略模式 的運用，比較常用的就是 Comparator 接口，它有非常多的實現方法，源碼中也有很多地方對其進行引用
如果有興趣，可以使用工具跟進查看一下，這里就不做過多的分析了
優缺點
優點
- 策略模式符合開閉原則
- 避免了代碼中過多的 if...else 和switch 語句的出現
- 使用策略模式可以提高算法的保密性和安全性
缺點
- 客戶端必須知道素有的策略，並決定使用哪一種
- 代碼中會出現比較多的策略類，增加維護難度
源碼
本文源碼：https://git.io/JeaYZ
歡迎star
推薦閱讀和參考資料：
https://www.cnblogs.com/java-my-life/archive/2012/05/10/2491891.html