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

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

設計模式 - 策略模式

定義

結構

類圖結構：

簡單代碼實現

改造

再改造

總結

應用場景

常用來解決的問題

在JDK中的體現

優缺點

優點

缺點

源碼

設計模式 - 策略模式

設計模式 - 策略模式

設計模式 - 委派模式

設計模式 - 動態代理原理及模仿JDK Proxy 寫一個屬於自己的動態代理

設計模式 - 工廠模式

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結