1.概述
在軟體開發中也常常遇到類似的情況，實作某一個功能有多種算法或者政策，我們可以根據環境或者條件的不同選擇不同的算法或者政策來完成該功能。如查找、排序等，一種常用的方法是寫死(Hard Coding)在一個類中，如需要提供多種查找算法，可以将這些算法寫到一個類中，在該類中提供多個方法，每一個方法對應一個具體的查找算法；當然也可以将這些查找算法封裝在一個統一的方法中，通過if…else…或者case等條件判斷語句來進行選擇。這兩種實作方法我們都可以稱之為寫死，如果需要增加一種新的查找算法，需要修改封裝算法類的源代碼；更換查找算法，也需要修改用戶端調用代碼。在這個算法類中封裝了大量查找算法，該類代碼将較複雜，維護較為困難。如果我們将這些政策包含在用戶端，這種做法更不可取，将導緻用戶端程式龐大而且難以維護，如果存在大量可供選擇的算法時問題将變得更加嚴重。
例子1：一個菜單功能能夠根據使用者的“皮膚”首選項來決定是否采用水準的還是垂直的排列形式。同僚可以靈活增加菜單那的顯示樣式。
例子2：出行旅遊：我們可以有幾個政策可以考慮：可以騎自行車，汽車，做火車，飛機。每個政策都可以得到相同的結果，但是它們使用了不同的資源。選擇政策的依據是費用，時間，使用工具還有每種方式的友善程度 。
設計模式之21 - 政策模式Strategy
2.問題
如何讓算法和對象分開來，使得算法可以獨立于使用它的客戶而變化？
3.解決方案
政策模式：定義一系列的算法,把每一個算法封裝起來, 并且使它們可互相替換。本模式使得算法可獨立于使用它的客戶而變化。也稱為政策模式(Policy)。（Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it. ）
政策模式把對象本身和運算規則區分開來，其功能非常強大，因為這個設計模式本身的核心思想就是面向對象程式設計的多形性的思想。
4.适用性
當存在以下情況時使用Strategy模式
1）• 許多相關的類僅僅是行為有異。 “政策”提供了一種用多個行為中的一個行為來配置一個類的方法。即一個系統需要動态地在幾種算法中選擇一種。
2）• 需要使用一個算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的算法。當這些變體實作為一個算法的類層次時 ,可以使用政策模式。
3）• 算法使用客戶不應該知道的資料。可使用政策模式以避免暴露複雜的、與算法相關的資料結構。
4）• 一個類定義了多種行為 , 并且這些行為在這個類的操作中以多個條件語句的形式出現。将相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。
5.結構
設計模式之21 - 政策模式Strategy
6.模式的組成
環境類(Context):用一個ConcreteStrategy對象來配置。維護一個對Strategy對象的引用。可定義一個接口來讓Strategy通路它的資料。
抽象政策類(Strategy):定義所有支援的算法的公共接口。 Context使用這個接口來調用某ConcreteStrategy定義的算法。
具體政策類(ConcreteStrategy):以Strategy接口實作某具體算法。
7.效果
Strategy模式有下面的一些優點：
1) 相關算法系列 Strategy類層次為Context定義了一系列的可供重用的算法或行為。 繼承有助于析取出這些算法中的公共功能。
2) 提供了可以替換繼承關系的辦法： 繼承提供了另一種支援多種算法或行為的方法。你可以直接生成一個Context類的子類，進而給它以不同的行為。但這會将行為硬行編制到 Context中，而将算法的實作與Context的實作混合起來,進而使Context難以了解、難以維護和難以擴充，而且還不能動态地改變算法。最後你得到一堆相關的類 , 它們之間的唯一差别是它們所使用的算法或行為。 将算法封裝在獨立的Strategy類中使得你可以獨立于其Context改變它，使它易于切換、易于了解、易于擴充。
3) 消除了一些if else條件語句 ：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件語句來選擇合适的行為。将行為封裝在一個個獨立的Strategy類中消除了這些條件語句。含有許多條件語句的代碼通常意味着需要使用Strategy模式。
4) 實作的選擇 Strategy模式可以提供相同行為的不同實作。客戶可以根據不同時間 /空間權衡取舍要求從不同政策中進行選擇。
Strategy模式缺點:
1)用戶端必須知道所有的政策類，并自行決定使用哪一個政策類: 本模式有一個潛在的缺點，就是一個客戶要選擇一個合适的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實作問題。是以僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
2 ) Strategy和Context之間的通信開銷 ：無論各個ConcreteStrategy實作的算法是簡單還是複雜, 它們都共享Strategy定義的接口。是以很可能某些 ConcreteStrategy不會都用到所有通過這個接口傳遞給它們的資訊；簡單的 ConcreteStrategy可能不使用其中的任何資訊！這就意味着有時Context會建立和初始化一些永遠不會用到的參數。如果存在這樣問題 , 那麼将需要在Strategy和Context之間更進行緊密的耦合。
3 )政策模式将造成産生很多政策類：可以通過使用享元模式在一定程度上減少對象的數量。 增加了對象的數目 Strategy增加了一個應用中的對象的數目。有時你可以将 Strategy實作為可供各Context共享的無狀态的對象來減少這一開銷。任何其餘的狀态都由 Context維護。Context在每一次對Strategy對象的請求中都将這個狀态傳遞過去。共享的 Strategy不應在各次調用之間維護狀态。
8.實作
1)出行旅遊：
uml：
設計模式之21 - 政策模式Strategy
代碼實作：
[php] view plain copy print ?
- <?php
- interface TravelStrategy{
- public function travelAlgorithm();
- }
- class AirPlanelStrategy implements TravelStrategy {
- public function travelAlgorithm(){
- echo "travel by AirPlain", "<BR>\r\n";
- }
- }
- class TrainStrategy implements TravelStrategy {
- public function travelAlgorithm(){
- echo "travel by Train", "<BR>\r\n";
- }
- }
- class BicycleStrategy implements TravelStrategy {
- public function travelAlgorithm(){
- echo "travel by Bicycle", "<BR>\r\n";
- }
- }
- class PersonContext{
- private $_strategy = null;
- public function __construct(TravelStrategy $travel){
- $this->_strategy = $travel;
- }
- public function setTravelStrategy(TravelStrategy $travel){
- $this->_strategy = $travel;
- }
- public function travel(){
- return $this->_strategy ->travelAlgorithm();
- }
- }
- // 乘坐火車旅行
- $person = new PersonContext(new TrainStrategy());
- $person->travel();
- // 改騎自行車
- $person->setTravelStrategy(new BicycleStrategy());
- $person->travel();
- ?>
2)排序政策:某系統提供了一個用于對數組資料進行操作的類，該類封裝了對數組的常見操作，
如查找數組元素、對數組元素進行排序等。現以排序操作為例，使用政策模式設計該數組操作類，
使得用戶端可以動态地更換排序算法，可以根據需要選擇冒泡排序或選擇排序或插入排序，
也能夠靈活地增加新的排序算法。
9.與其他相關模式
1）狀态模式
政策模式和其它許多設計模式比較起來是非常類似的。政策模式和狀态模式最大的差別就是政策模式隻是的條件選擇隻執行一次，而狀态模式是随着執行個體參數（對象執行個體的狀态）的改變不停地更改執行模式。換句話說，政策模式隻是在
對象初始化的時候更改執行模式，而狀态模式是根據對象執行個體的周期時間而動态地改變對象執行個體的執行模式。
•可以 通過環境類狀态的個數來決定是使用政策模式還是狀态模式。 • 政策模式的環境類自己選擇一個具體政策類，具體政策類無須關心環境類；而 狀态模式的環境類由于外在因素需要放進一個具體狀态中， 以便通過其方法實作狀态的切換，是以 環境類和狀态類之間存在一種雙向的關聯關系。 •使用政策模式時， 用戶端需要知道所選的具體政策是哪一個，而使用狀态模式時， 用戶端無須關心具體狀态，環境類的狀态會根據使用者的操作自動轉換。 •如果系統中某個類的對象存在多種狀态，不同狀态下行為有差異，而且這些 狀态之間可以發生轉換時使用狀态模式； 如果系統中某個類的某一行為存在多種實作方式，而且 這些實作方式可以互換時使用政策模式。
2）簡單工廠的差別：點選打開連結
工廠模式是建立型模式 ，它關注對象建立，提供建立對象的接口. 讓對象的建立與具體的使用客戶無關。
政策模式是對象行為型模式 ，它關注行為和算法的封裝 。它定義一系列的算法,把每一個算法封裝起來, 并且使它們可互相替換。使得算法可獨立于使用它的客戶而變化
用我們上面提到旅行的例子：
我們去旅行。政策模式的做法：有幾種方案供你選擇旅行，選擇火車好呢還是騎自行車，完全有客戶自行決定去建構旅行方案（比如你自己需要去買火車票，或者機票）。而工廠模式是你決定哪種旅行方案後，不用關注這旅行方案怎麼給你建立，也就是說你告訴我方案的名稱就可以了，然後由工廠代替你去建構具體方案（工廠代替你去買火車票）。
上面的例子裡面client代碼：
$person = new PersonContext(new TrainStrategy());
$person->travel();
我們看到客戶需要自己去建立具體旅行（new TrainStrategy()）執行個體。傳遞的是具體執行個體。
而工廠模式你隻要告訴哪種旅行就可以了，不是傳遞一個具體執行個體，而是一個辨別（旅行方案辨別）。
10.總結與分析
1） 政策模式是一個比較容易了解和使用的設計模式， 政策模式是對算法的封裝， 它把算法的責任和算法本身分割開， 委派給不同的對象管理。政策模式通常 把一個系列的算法封裝到一系列的政策類裡面，作為一個抽象政策類的子類。用一句話來說，就是“準備一組算法，并将每一個算法封裝起來，使得它們可以互換”。 2）在 政策模式中，應當由用戶端自己決定在什麼情況下使用什麼具體政策角色。 3) 政策模式僅僅封裝算法，提供新算法插入到已有系統中，以及老算法從系統中“退休”的友善，政策模式并不決定在何時使用何種算法，算法的選擇由用戶端來決定。這在一定程度上提高了系統的靈活性，但是用戶端需要了解所有具體政策類之間的差別，以便選擇合适的算法，這也是政策模式的缺點之一，在一定程度上增加了用戶端的使用難度。
原文連結： http://blog.csdn.net/hguisu/article/details/7558249