《設計模式之禪》之策略模式

策略模式是一種比較簡單的模式，也叫做政策模式，其定義如下:定義一組演算法，將每個演算法都封裝起來，並且使它們之間可以互換。

策略模式使用的是物件導向的繼承和多型機制，我們看看策略模式的三個角色:

它也叫上下文角色，起承上啟下封裝作用，遮蔽高層模組對策略、演算法的直接訪問，封裝可能存在的變化。

策略、演算法家族的抽象，通常為介面，定義每個策略或演算法必須具有的方法和屬性。

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

a.演算法可以自由切換

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

b.避免使用多重條件判斷

如果沒有策略模式，我們想想看會是什麼樣子？

乙個策略家族有5個策略演算法，一會要使用a策略，一會要使用b策略，怎麼設計呢？使用多重的條件語句？多重條件語句不易維護，而且出錯的概率大大增強。使用策略模式後，可以由其他模組決定採用何種策略，策略家族對外提供的訪問介面就是封裝類，簡化了操作，同時避免了條件語句判斷。

c.擴充套件性良好

只要實現介面就可以，其他都不用修改，類似於乙個可反覆拆卸的外掛程式，大大符合ocp原則(開閉原則)。

a.策略類數量增多

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

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

上層模組必須知道有哪些策略，然後才能決定使用哪乙個策略，這與迪公尺特法則相違背的，我只想使用乙個策略，我憑什麼就要了解這個策略呢？那要你的封裝類還有什麼意義?這是原裝策略模式的乙個缺點，幸運的是，我們可以使用其他模式來修正這個缺陷，如工廠方法模式、**模式或享元模式。

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

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

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

c.需要遮蔽演算法規則的場景。

現在的科技發展得很快，人腦記憶是有限得，太多得演算法你只要知道乙個名字就可以了，傳遞相關得數字進來，反饋乙個運算結果，就ok了。

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

注意:策略列舉是乙個非常優秀和方便的模式，但是它受列舉型別的限制，每個列舉項都是public、final、static的，擴充套件性受到了一定的約束，因此在系統開發中，策略列舉一般擔當不經常發生變化的角色。

策略模式是乙個非常簡便的模式。它在專案中使用得非常多，但它單獨使用得地方就比較少了，因為它有致命缺陷:所有得策略都需要暴露出去，這樣才方便客戶端決定使用哪乙個策略。

**例子: