摘要：可以使用其他模式來修正這個缺陷，如工廠方法模式代理模式或享元模式。我們的策略模式只是實現了策略的管理，但是沒有嚴格地定義適當的場景使用適當的策略，在實際項目中，一般通過工廠方法模式來實現策略類的聲明。源碼地址參考文獻設計模式之禪

Define a family of algorithms,encapsulate each one,and make them interchangeable.
定義一組算法，將每個算法都封裝起來，并且使它們之間可以互換。

策略模式使用的就是面向對象的繼承和多態機制，非常容易理解和掌握

策略、算法家族的抽象，通常為接口，也可以是抽象類，定義每個策略或算法必須具有的方法和屬性。

public interface Strategy {

    /**
     * 策略模式的運算法則
     */
    void doSomething();
}

實現抽象策略中的操作，該類含有具體的算法

public class ConcreteStrategyA implements Strategy {
    @Override
    public void doSomething() {
        System.out.println("具體策略A的運算法則");
    }
}

public class ConcreteStrategyB implements Strategy {
    @Override
    public void doSomething() {
        System.out.println("具體策略B的運算法則");
    }
}

也叫做上下文類或環境類，起承上啟下封裝作用，屏蔽高層模塊對策略、算法的直接訪問，封裝可能存在的變化。

策略模式的重點就是封裝角色，它是借用了代理模式的思路，和代理模式的差別就是策略模式的封裝角色和被封裝的策略類不用是同一個接口，如果是同一個接口那就成為了代理模式。

public class Context {

    /**
     * 抽象策略
     */
    private Strategy strategy;

    /**
     * 構造函數設置具體策略
     *
     * @param strategy
     */
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    /**
     * 封裝后的策略方法
     */
    public void executeStrategy() {
        this.strategy.doSomething();
    }
}

public class Client {

    public static void main(String[] args) {
        // 聲明一個具體的策略
        Strategy strategyA = new ConcreteStrategyA();
        // 聲明上下文對象
        Context contextA = new Context(strategyA);
        // 執行封裝后的方法
        contextA.executeStrategy();

        Strategy strategyB = new ConcreteStrategyB();
        Context contextB = new Context(strategyB);
        contextB.executeStrategy();
    }
}

算法可以自由切換

這是策略模式本身定義的，只要實現抽象策略，它就成為策略家族的一個成員，通過封裝角色對其進行封裝，保證對外提供“可自由切換”的策略。

避免使用多重條件判斷

如果沒有策略模式，一個策略家族有5個策略算法，一會要使用A策略，一會要使用B策略，怎么設計呢？使用多重的條件語句？多重條件語句不易維護，而且出錯的概率大大增強。使用策略模式后，可以由其他模塊決定采用何種策略，策略家族對外提供的訪問接口就是封裝類，簡化了操作，同時避免了條件語句判斷。

擴展性良好

在現有的系統中增加一個策略太容易了，只要實現接口就可以了，其他都不用修改，類似于一個可反復拆卸的插件，這大大地符合了OCP原則。

策略類數量增多

每一個策略都是一個類，復用的可能性很小，類數量增多。

所有的策略類都需要對外暴露

上層模塊必須知道有哪些策略，然后才能決定使用哪一個策略，這與迪米特法則是相違背的（只是想使用一個策略，卻要要了解這個策略）。可以使用其他模式來修正這個缺陷，如工廠方法模式、代理模式或享元模式。

多個類只有在算法或行為上稍有不同的場景。

算法需要自由切換的場景。

例如，算法的選擇是由使用者決定的，或者算法始終在進化，特別是一些站在技術前沿的行業，連業務專家都無法給你保證這樣的系統規則能夠存在多長時間，在這種情況下策略模式是你最好的助手。

需要屏蔽算法規則的場景。

現在的科技發展得很快，人腦的記憶是有限的（就目前來說是有限的），太多的算法你只要知道一個名字就可以了，傳遞相關的數字進來，反饋一個運算結果，萬事大吉。

如果系統中的一個策略家族的具體策略數量超過4個，則需要考慮使用混合模式，解決策略類膨脹和對外暴露的問題，否則日后的系統維護就會成為一個燙手山芋，誰都不想接。

策略模式是一個非常簡單的模式（主要是用了Java繼承與多態的機制）。它在項目中使用得非常多，但多帶帶使用的地方就比較少了，因為它有致命缺陷：所有的策略都需要暴露出去，這樣才方便客戶端決定使用哪一個策略。我們的策略模式只是實現了策略的管理，但是沒有嚴格地定義“適當的場景”使用“適當的策略”，在實際項目中，一般通過工廠方法模式來實現策略類的聲明。

定義

它是一個枚舉。
它是一個濃縮了的策略模式的枚舉。

啥意思？來看代碼：

定義一個計算器（枚舉類）

public enum Calculator {
    PLUS("+") {
        public int exec(int x, int y) {
            return x + y;
        }
    },
    MINUS("-") {
        public int exec(int x, int y) {
            return x - y;
        }
    };

    private final String symbol;

    Calculator(String symbol) {
        this.symbol = symbol;
    }

    public String getSymbol() {
        return this.symbol;
    }

    /**
     * 聲明一個抽象方法
     * 枚舉類型中的抽象方法必須被它的所有常量中的具體方法所覆蓋（被稱為特定于常量的方法實現）
     */
    public abstract int exec(int a, int b);
}

把原有定義在抽象策略中的方法移植到枚舉中，每個枚舉成員就成為一個具體策略

客戶端代碼

public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 10;
        System.out.println(x + " + " + y + " = " + Calculator.PLUS.exec(x, y));
        System.out.println(x + " - " + y + " = " + Calculator.MINUS.exec(x, y));
    }
}

代碼量非常少，而且還有一個顯著的優點：真實地面向對象

Calculator.PLUS.exec(x, y)類似于“拿出計算器（Calculator），對x和y進行加法運算（MINUS），并立刻執行(exec)”，這與我們日常接觸邏輯非常相似

策略枚舉是一個非常優秀和方便的模式（《Effective Java》中枚舉相關條目也有詳細介紹該模式），但是它受枚舉類型的限制，每個枚舉項都是public、final、static的，擴展性受到了一定的約束，因此在系統開發中，策略枚舉一般擔當不經常發生變化的角色。

源碼地址：https://gitee.com/tianranll/j...

參考文獻：《設計模式之禪》、《Effective Java》