在軟件開發中也常常遇到類似的情況，實現某一個功能有多種算(suan)法或者策略，我們可(ke)以根據(ju)環境(jing)或(huo)(huo)者(zhe)條件(jian)的(de)不同選擇不同的(de)算法或(huo)(huo)者(zhe)策略來(lai)完(wan)成(cheng)該功能。如查找、排序等，一種常用的方法是硬編碼(Hard Coding)在一個類中，如需要提供多種查找算法，可以將這些算法寫到一個類中，在該類中提供多個方法，每一個方法對應一個具體的查找算法；當然也可以將這些查找算法封裝在一個統一的方法中，通過if…else…或者case等條件判斷語句來進行選擇。這兩種實現方法我們都可以稱之為硬編碼，如果需要增加一種新的查找算法，需要修改封裝算法類的源代碼；更換查找算法，也需要修改客戶端調用代碼。在這個算法類中封裝了大量查找算法，該類代碼將較復雜，維護較為困難。如果我們將這(zhe)些(xie)策略(lve)包含在客戶端(duan)，這種做法(fa)更不可取，將導致客戶端(duan)程序龐大而且難以維(wei)護，如果(guo)存在(zai)大量可供選擇的算法(fa)時問題將變得(de)更加(jia)嚴重。

例(li)子1：一個菜單(dan)功能(neng)(neng)能(neng)(neng)夠根據用戶的“皮膚”首選(xuan)項來決(jue)定是否采用水平的還(huan)是垂直的排列形式。同事可以靈(ling)活增加(jia)菜單(dan)那的顯示樣式。

例子2：出行旅游：我們可(ke)(ke)以有(you)幾(ji)個(ge)策(ce)略可(ke)(ke)以考慮：可(ke)(ke)以騎自行車，汽車，做火車，飛機。每個(ge)策(ce)略都可(ke)(ke)以得到相同(tong)的(de)結果，但是它(ta)們使用了不(bu)同(tong)的(de)資源。選(xuan)擇(ze)策(ce)略的(de)依據(ju)是費用，時間，使用工(gong)具還有(you)每種方(fang)(fang)式的(de)方(fang)(fang)便程度 。

如何讓算法和對象分開來，使得算法可以獨立于使用它的客戶而變化？

：定義一系列的算法,把每一個算法封裝起來, 并且使它們可相互替換。本模式使得算法可獨立于使用它的客戶而變化。。（Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it. ）

策略模式(shi)把對象本身和運算規則區分開(kai)來，其(qi)功能非常(chang)強大，因為這個設(she)計模式本身的(de)核心思(si)想就是面(mian)向(xiang)對象(xiang)編程的(de)多形性的(de)思(si)想。

當存在以下情況時使用Strategy模式
1）? 許多相關的類僅僅是行為有異。 “策略”提供了一種用多個行為中的一個行為來配置一個類的方法。即一個系統需要動態地在幾種算法中選擇一種。
2）? 需要使用一個算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的算法。當這些變體實現為一個算法的類層次時 ,可以使用策略模式。
3）? 算法使用客戶不應該知道的數據。可使用策略模式以避免暴露復雜的、與算法相關的數據結構。
4）? 一個類定義了多種行為 , 并且這些行為在這個類的操作中以多個條件語句的形式出現。將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。

:用一個ConcreteStrategy對象來配置。維護一個對Strategy對象的引用。可定義一個接口來讓Strategy訪問它的數據。
定義所有支持的算法的公共接口。 Context使用這個接口來調用某ConcreteStrategy定義的算法。
:以Strategy接口(kou)實現(xian)某具(ju)體算法。

Strategy模式有下面的一些優點：
1) 相(xiang)關算法系(xi)列(lie) Strategy類層次為Context定義了一系列的可供重用的算法或行為。 繼承有助于析取出這些算法中的公共功能。
2) 提供了可以替換(huan)繼承關系(xi)的辦法： 繼承提供了另一種支持多種算法或行為的方法。你可以直接生成一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編制到 Context中，而將算法的實現與Context的實現混合起來,從而使Context難以理解、難以維護和難以擴展，而且還不能動態地改變算法。最后你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的算法或行為。 將算法封裝在獨立的Strategy類中使得你可以獨立于其Context改變它，使它易于切換、易于理解、易于擴展。
3) 消除了一(yi)些(xie)if else條件語(yu)句 ：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件語句來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件語句。含有許多條件語句的代碼通常意味著需要使用Strategy模式。
4) 實(shi)現的(de)選(xuan)擇(ze) Strategy模式可以提供相同行為的不同實現。客戶可以根據不同時間 /空間權衡取舍要求從不同策略中進行選擇。

Strategy模(mo)式缺點:

1)客(ke)戶端必須知道所有的策(ce)略類，并自(zi)行決定使(shi)用哪一個策(ce)略類:  本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
2 ) Strategy和Context之間的(de)通信開銷(xiao) ：無論各個ConcreteStrategy實現的算法是簡單還是復雜, 它們都共享Strategy定義的接口。因此很可能某些 ConcreteStrategy不會都用到所有通過這個接口傳遞給它們的信息；簡單的 ConcreteStrategy可能不使用其中的任何信息！這就意味著有時Context會創建和初始化一些永遠不會用到的參數。如果存在這樣問題 , 那么將需要在Strategy和Context之間更進行緊密的耦合。
3 )策略(lve)模式將造(zao)成(cheng)產生很多策略(lve)類：可以(yi)通(tong)過(guo)使用享(xiang)元模式在一定程(cheng)度上(shang)減少對(dui)象(xiang)(xiang)的(de)(de)數(shu)(shu)量。 增加了(le)對(dui)象(xiang)(xiang)的(de)(de)數(shu)(shu)目 Strategy增加了(le)一個(ge)應用中(zhong)的(de)(de)對(dui)象(xiang)(xiang)的(de)(de)數(shu)(shu)目。有時你可以(yi)將 Strategy實現為可供各Context共享(xiang)的(de)(de)無狀態(tai)(tai)的(de)(de)對(dui)象(xiang)(xiang)來減少這(zhe)(zhe)一開銷。任(ren)何其余的(de)(de)狀態(tai)(tai)都由 Context維(wei)護(hu)。Context在每一次(ci)(ci)對(dui)Strategy對(dui)象(xiang)(xiang)的(de)(de)請(qing)求中(zhong)都將這(zhe)(zhe)個(ge)狀態(tai)(tai)傳遞過(guo)去(qu)。共享(xiang)的(de)(de) Strategy不應在各次(ci)(ci)調用之(zhi)間(jian)維(wei)護(hu)狀態(tai)(tai)。

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";

}

}

/**

*


環境(jing)類(Context):用一個ConcreteStrategy對(dui)象來配(pei)置(zhi)。維護一個對(dui)Strategy對(dui)象的引用。可定義(yi)一個接(jie)口來讓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-&gt;setTravelStrategy(new BicycleStrategy());
\)person->travel();
?>

 

2)排(pai)序策(ce)略(lve):某系(xi)統提供了(le)一(yi)個用于(yu)對(dui)數組數據進行操作的類(lei)，該類(lei)封裝了(le)對(dui)數組的常(chang)見操作，

如查找(zhao)數組(zu)元素、對(dui)數組(zu)元素進行排序等。現以(yi)排序(xu)操(cao)作為例，使用策略模式設計(ji)該數(shu)組操(cao)作類，

使(shi)得客戶端可以動態地更(geng)換排序(xu)算法，可以根據需要選(xuan)擇(ze)冒泡排序(xu)或選(xuan)擇(ze)排序(xu)或插入排序(xu)，

也能夠靈活地增(zeng)加新的(de)排序(xu)算法。

1）

策(ce)略(lve)模式和其它許多設計模式比較(jiao)起來是非常類似的。策(ce)略(lve)模式和狀態模式最大(da)的區(qu)別就是策(ce)略(lve)模式只是(shi)的條件選擇只執行一(yi)次，而狀態(tai)模(mo)(mo)式(shi)是隨著實(shi)例(li)參數（對(dui)象實(shi)例(li)的狀態(tai)）的改(gai)變(bian)不停地更改(gai)執(zhi)行模(mo)(mo)式(shi)。換句話說，策(ce)略模(mo)(mo)式(shi)只是在

對象初始化的時候(hou)更改執行模式，而狀(zhuang)態(tai)模(mo)式(shi)是(shi)根據對象實例(li)的周(zhou)期時間而動態(tai)地(di)改(gai)變對象實例(li)的執行模(mo)式(shi)。

?可(ke)以通過環境類狀態的個數來決(jue)定是使用策(ce)略模式還是狀態模式。

?策(ce)略(lve)(lve)模式的環境(jing)類(lei)自己選擇一個(ge)具體(ti)策(ce)略(lve)(lve)類(lei)，具體(ti)策(ce)略(lve)(lve)類(lei)無須(xu)關心(xin)環境(jing)類(lei)；而狀態模式的環境類由于外(wai)在因素需要放進一個具體狀態中，

以便(bian)通過其方法實現狀態的切換，因(yin)此環境類和狀態類之(zhi)間(jian)存在一種雙向的(de)關(guan)聯關(guan)系。

?使(shi)用策略模式時，客戶(hu)端(duan)需要(yao)知(zhi)道所(suo)選的具體(ti)策略(lve)是(shi)哪一個(ge)，而使用狀(zhuang)態(tai)模式時，客戶端無須關心具體狀態(tai)，環境(jing)類的狀態會(hui)根據用戶的操作自動轉換。

?如(ru)果系統中某(mou)個類的對象(xiang)存在多種狀(zhuang)態(tai)，不同狀(zhuang)態(tai)下行為有差異，而且這些狀(zhuang)態之間可(ke)以發生轉換時使(shi)用狀(zhuang)態模式(shi)；

如果系統中(zhong)某個(ge)類的(de)某一行(xing)為(wei)存在多種實現方式，而(er)且這(zhe)些(xie)實現方式可以互換時(shi)使用策略模式。

2）的區別：

工廠模式是創建型模式 ，它關注對象創建，提供創建對象的接口. 讓對象的創建與具體的使用客戶無關。
策略模(mo)式(shi)是對象(xiang)行為(wei)型模(mo)式(shi) ，它關注行為(wei)和(he)算(suan)法(fa)的封裝 。它定(ding)義一(yi)系列的算(suan)法(fa),把每一(yi)個(ge)算(suan)法(fa)封裝起來, 并且使(shi)(shi)它們(men)可(ke)相互替(ti)換。使(shi)(shi)得算(suan)法(fa)可(ke)獨立于使(shi)(shi)用(yong)它的客戶而變化(hua)

用我們上面提到旅行的例子：
我們(men)去(qu)(qu)旅行(xing)(xing)。策略模式(shi)的做(zuo)法：有幾種方(fang)案供你(ni)(ni)選(xuan)擇旅行(xing)(xing)，選(xuan)擇火車(che)(che)好呢還是(shi)(shi)騎自行(xing)(xing)車(che)(che)，完全有客戶自行(xing)(xing)決定(ding)去(qu)(qu)構(gou)(gou)建旅行(xing)(xing)方(fang)案（比如你(ni)(ni)自己需要去(qu)(qu)買火車(che)(che)票(piao)，或者(zhe)機票(piao)）。而工(gong)廠模式(shi)是(shi)(shi)你(ni)(ni)決定(ding)哪(na)種旅行(xing)(xing)方(fang)案后，不用關注這旅行(xing)(xing)方(fang)案怎(zen)么給你(ni)(ni)創建，也就是(shi)(shi)說你(ni)(ni)告訴我方(fang)案的名稱就可以了，然后由工(gong)廠代替你(ni)(ni)去(qu)(qu)構(gou)(gou)建具體方(fang)案（工(gong)廠代替你(ni)(ni)去(qu)(qu)買火車(che)(che)票(piao)）。

上面的例子里面client代碼：
$person = new PersonContext(new TrainStrategy());
$person->travel();
我們看到客戶需要自己去創建具體旅行（new TrainStrategy()）實例。傳遞的是具體實例。
而工廠模式你只要告(gao)訴(su)哪種旅行(xing)就可以了，不是(shi)傳遞一(yi)個(ge)具體實例(li)，而是(shi)一(yi)個(ge)標識（旅行(xing)方案標識）。

1）是一個比較容(rong)易(yi)理解(jie)和使用的設計模式，策略模式(shi)是對(dui)算法的(de)封裝，它(ta)把算法(fa)的責任(ren)和算法(fa)本(ben)身分割開(kai)，委派給(gei)不同(tong)的對象管理。策(ce)略模式通常把一(yi)個系列的(de)算法封裝到一(yi)系列的(de)策略類里面(mian)，作為一(yi)個抽(chou)象策略(lve)類的子類。用一(yi)句話來說，就(jiu)是(shi)“準備一(yi)組算法，并(bing)將每(mei)一(yi)個算法封(feng)裝(zhuang)起來，使得它們可以互換”。

2）在中，應當(dang)由客戶端自己決定在(zai)什(shen)么情況(kuang)下使用什(shen)么具體策略角色。2）

3）僅僅封裝算法，提供新算法插入到已有系統中，以及老算法從系統中“退休”的方便，策略模(mo)式并不決定(ding)在(zai)何(he)時使用何(he)種算(suan)法(fa)，算(suan)法(fa)的(de)選擇由客戶端來決定(ding)。這在(zai)一定(ding)程(cheng)度(du)上提(ti)高了(le)系統的(de)靈(ling)活性，但是客戶端需要理解所有(you)具體策略類之間的(de)區別(bie)，以便(bian)選擇合適的(de)算(suan)法(fa)，這也是策略模(mo)式的(de)缺點(dian)之一，在(zai)一定(ding)程(cheng)度(du)上增加了(le)客戶端的(de)使用難度(du)。

轉載指明原文出處：   設計模式 ( 十八 ) 策略模式Strategy（對象行為型）