在理解策略模式之前我們假設有這樣一個需求場景：我們在寫訂單支付場景的代碼時，客戶可以選擇多種支付方式，有銀聯支付、支付寶支付、微信支付、京東白條等等，然后我們就很可能就會撰寫出類似下面這樣的代碼：

/**
 * 訂單類，擁有一個支付方法
 *
 * @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

https://www.cnblogs.com/lewis0077/p/5133812.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/35306.html

標籤：設計模式

上一篇：Ubuntu Server 上在安裝Nginx時執行./confgiure后提示：C compiler cc is not found

下一篇：【設計模式】工廠方法模式

設計模式 - 策略模式

定義

結構

類圖結構：

簡單代碼實作

改造

再改造

總結

應用場景

常用來解決的問題

在JDK中的體現

優缺點

優點

缺點

原始碼