設計模式 ( 十八 ) 策略模式Strategy（對象行為型）

標籤：style   blog   http   color   使用   io   strong   資料   

設計模式 ( 十八 ) 策略模式Strategy（對象行為型）

1.概述

        在軟體開發中也經常遇到類似的情況，實現某一個功能有多種演算法或者策略，我們能夠依據環境或者條件的不同選擇不同的演算法或者策略來完畢該功能。如尋找、排序等，一種經常使用的方法是寫入程式碼(Hard Coding)在一個類中，如須要提供多種尋找演算法，能夠將這些演算法寫到一個類中，在該類中提供多個方法，每個方法相應一個詳細的尋找演算法；當然也能夠將這些尋找演算法封裝在一個統一的方法中，通過if…else…或者case等條件推斷語句來進行選擇。這兩種實現方法我們都能夠稱之為寫入程式碼，假設須要添加一種新的尋找演算法，須要改動封裝演算法類的源碼；更換尋找演算法，也須要改動client調用代碼。在這個演算法類中封裝了大量尋找演算法，該類代碼將較複雜，維護較為困難。假設我們將這些策略包括在client，這樣的做法更不可取，將導致client程式龐大並且難以維護，假設存在大量可供選擇的演算法時問題將變得更加嚴重。

範例1：一個菜單功能可以依據使用者的“皮膚”喜好設定來決定是否採用水平的還是垂直的排列形式。同事可以靈活添加菜單那的顯示樣式。

範例2：出行旅遊：我們能夠有幾個策略能夠考慮：能夠騎單車，汽車，做火車，飛機。每一個策略都能夠得到同樣的結果，可是它們使用了不同的資源。選擇策略的根據是費用，時間，使用工具還有每種方式的方便程度 。

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.結構

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)client必須知道全部的策略類，並自行決定使用哪一個策略類:  本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy究竟有何不同。此時可能不得不向客戶暴露詳細的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才須要使用Strategy模式。
2 ) Strategy和Context之間的通訊開銷 ：不管各個ConcreteStrategy實現的演算法是簡單還是複雜, 它們都共用Strategy定義的介面。因此非常可能某些 ConcreteStrategy不會都用到全部通過這個介面傳遞給它們的資訊；簡單的 ConcreteStrategy可能不使用當中的不論什麼資訊！這就意味著有時Context會建立和初始化一些永遠不會用到的參數。假設存在這樣問題 , 那麼將須要在Strategy和Context之間更進行緊密的耦合。
3 )策略模式將造成產生非常多策略類：能夠通過使用享元模式在一定程度上降低對象的數量。 添加了對象的數目 Strategy添加了一個應用中的對象的數目。有時你能夠將 Strategy實現為可供各Context共用的無狀態的對象來降低這一開銷。不論什麼其餘的狀態都由 Context維護。Context在每一次對Strategy對象的請求中都將這個狀態傳遞過去。共用的 Strategy不應在各次調用之間維護狀態。

8.實現

1)出行旅遊：

uml：

代碼實現：

<?php/*** 策略模式* 定義一系列的演算法,把每個演算法封裝起來, 而且使它們可相互替換。本模式使得演算法可獨立於使用它的客戶而變化**/ /*** 出行旅遊** */interface TravelStrategy{public function travelAlgorithm();} /** * 詳細策略類(ConcreteStrategy)1：乘坐飛機 */class AirPlanelStrategy implements TravelStrategy {public function travelAlgorithm(){echo "travel by AirPlain", "<BR>\r\n"; }} /** * 詳細策略類(ConcreteStrategy)2：乘坐火車 */class TrainStrategy implements TravelStrategy {public function travelAlgorithm(){echo "travel by Train", "<BR>\r\n"; }} /** * 詳細策略類(ConcreteStrategy)3：騎單車 */class BicycleStrategy implements TravelStrategy {public function travelAlgorithm(){echo "travel by Bicycle", "<BR>\r\n"; }} /** *  * 環境類(Context):用一個ConcreteStrategy對象來配置。維護一個對Strategy對象的引用。可定義一個介面來讓Strategy訪問它的資料。 * 演算法解決類，以提供客戶選擇使用何種解決方式： */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)排序策略:某系統提供了一個用於對數組資料進行操作的類，該類封裝了對數組的常見操作，

如尋找數組元素、對數組元素進行排序等。現以排序操作為例，使用原則模式設計該數組操作類，

使得client能夠動態地更換排序演算法，能夠依據須要選擇冒泡排序或選擇排序或插入排序，

也可以靈活地添加新的排序演算法。

9.與其它相關模式

1）狀態模式

策略模式和其他很多設計模式比較起來是很類似的。策略模式和狀態模式最大的差別就是策略模式僅僅是的條件選擇僅僅運行一次，而狀態模式是隨著執行個體參數（對象執行個體的狀態）的改變不停地更改運行模式。換句話說，策略模式僅僅是在

對象初始化的時候更改運行模式，而狀態模式是依據對象執行個體的周期時間而動態地改變對象執行個體的運行模式。

?能夠通過環境類狀態的個數來決定是使用原則模式還是狀態模式。?策略模式的環境類自己選擇一個詳細策略類，詳細策略類無須關心環境類；而狀態模式的環境類因為外在因素須要放進一個詳細狀態中，以便通過其方法實現狀態的切換，因此環境類和狀態類之間存在一種雙向的關聯關係。?使用原則模式時，client須要知道所選的詳細策略是哪一個，而使用狀態模式時，client無須關心詳細狀態，環境類的狀態會依據使用者的操作自己主動轉換。?假設系統中某個類的對象存在多種狀態，不同狀態下行為有差異，並且這些狀態之間能夠發生轉換時使用狀態模式；假設系統中某個類的某一行為存在多種實現方式，並且這些實現方式能夠互換時使用原則模式。

2）簡單工廠的差別：點擊開啟連結

原廠模式是建立型模式 ，它關注對象建立，提供建立對象的介面. 讓對象的建立與詳細的使用客戶無關。
策略模式是對象行為型模式 ，它關注行為和演算法的封裝 。它定義一系列的演算法,把每個演算法封裝起來, 而且使它們可相互替換。使得演算法可獨立於使用它的客戶而變化

用我們上面提到旅行的範例：
我們去旅行。策略模式的做法：有幾種方案供你選擇旅行，選擇火車好呢還是騎單車，全然有客戶自行決定去構建旅行方案（比方你自己須要去買火車票，或者機票）。而原廠模式是你決定哪種旅行方案後，不用關注這旅行方案怎麼給你建立，也就是說你告訴我方案的名稱就能夠了，然後由工廠取代你去構建詳細方案（工廠取代你去買火車票）。

上面的範例裡面client代碼：
$person = new PersonContext(new TrainStrategy());
$person->travel();
我們看到客戶須要自己去建立詳細旅行（new TrainStrategy()）執行個體。傳遞的是詳細執行個體。
而原廠模式你僅僅要告訴哪種旅行就能夠了，不是傳遞一個詳細執行個體，而是一個標識（旅行方案標識）。

10.總結與分析

1）策略模式是一個比較easy理解和使用的設計模式，策略模式是對演算法的封裝，它把演算法的責任和演算法本身切割開，委派給不同的對象管理。策略模式通常把一個系列的演算法封裝到一系列的策略類裡面，作為一個抽象策略類的子類。用一句話來說，就是“準備一組演算法，並將每個演算法封裝起來，使得它們能夠互換”。2）在策略模式中，應當由client自己決定在什麼情況下使用什麼詳細策略角色。2）3）策略模式只封裝演算法，提供新演算法插入到已有系統中，以及老演算法從系統中“退休”的方便，策略模式並不決定在何時使用何種演算法，演算法的選擇由client來決定。這在一定程度上提高了系統的靈活性，可是client須要理解全部詳細策略類之間的差別，以便選擇合適的演算法，這也是策略模式的缺點之中的一個，在一定程度上添加了client的使用難度。

轉載指明原文出處：hguisu   設計模式 ( 十八 ) 策略模式Strategy（對象行為型） http://blog.csdn.net/hguisu/article/details/7558249