策略模式（Strategy）：它定義了一系列的算法，并將每一個(gè)算法封裝起來，而且使它們還可以相互替換。策略模式讓算法的變化不會(huì)影響到使用算法的客戶。策略模式和 Template 模式要解決的問題是相同（類似）的，都是為了給業(yè)務(wù)邏輯（算法）具體實(shí)現(xiàn)和抽象接口之間的解耦。策略模式將邏輯（算法）封裝到一個(gè)類（Context）里面，通過組合的方式將具體算法的實(shí)現(xiàn)在組合對(duì)象中實(shí)現(xiàn)，再通過委托的方式將抽象接口的實(shí)現(xiàn)委托給組合對(duì)象實(shí)現(xiàn)。State 模式也有類似的功能，他們之間的區(qū)別將在討論中給出。
UML圖
優(yōu)點(diǎn)：
1、 簡化了單元測試，因?yàn)槊總€(gè)算法都有自己的類，可以通過自己的接口單獨(dú)測試。
2、 避免程序中使用多重條件轉(zhuǎn)移語句，使系統(tǒng)更靈活，并易于擴(kuò)展。
3、 遵守大部分GRASP原則和常用設(shè)計(jì)原則，高內(nèi)聚、低偶合。
缺點(diǎn)：
1、 因?yàn)槊總€(gè)具體策略類都會(huì)產(chǎn)生一個(gè)新類，所以會(huì)增加系統(tǒng)需要維護(hù)的類的數(shù)量。
2、 在基本的策略模式中，選擇所用具體實(shí)現(xiàn)的職責(zé)由客戶端對(duì)象承擔(dān)，并轉(zhuǎn)給策略模式的Context對(duì)象
實(shí)現(xiàn)示例：
Strategy.h
#include <iostream> #include <string> #include <memory> using namespace std; //strategy抽象類，用作接口 class Strategy { public: virtual string substitute(string str)=0; virtual ~Strategy() { cout<<" in the destructor of Strategy"<<endl; } }; class ChineseStrategy:public Strategy { public: string substitute(string str) { int index=str.find("520"); string tempstr=str.replace(index,3,"我愛你"); return tempstr; } ~ChineseStrategy() { cout<<"in the destructor of ChineseStrategy"<<endl; } }; class EnglishStrategy:public Strategy { public: string substitute(string str) { int index=str.find("520"); string tempstr=str.replace(index,3,"i love ou"); return tempstr; } ~EnglishStrategy() { cout<<" in the destructor of ChineseStrategy"<<endl; } }; //Context類 class Translator { private: auto_ptr<Strategy> strategy; //在客戶代碼中加入算法（stategy）類型的指針。 public: ~Translator() { cout<<" in the destructor of Translator"<<endl; } void set_strategy(auto_ptr<Strategy> strategy) { this->strategy=strategy; } string translate(string str) { if(0==strategy.get()) return ""; return strategy->substitute(str); } }; Strategy.cpp
#include "Strategy.h" int main(int argc, char *argv) { string str("321520"); Translator *translator=new Translator; //未指定strategy的時(shí)候 cout<<"No Strategy"<<endl; translator->translate(str); cout<<"---------------"<<endl; //翻譯成中文 auto_ptr<Strategy> s1(new ChineseStrategy); translator->set_strategy(s1); cout<<"Chinese Strategy"<<endl; cout<<translator->translate(str)<<endl; cout<<"---------------"<<endl; //翻譯成英文 auto_ptr<Strategy> s2(new EnglishStrategy); translator->set_strategy(s2); cout<<"English Strategy"<<endl; cout<<translator->translate(str)<<endl; cout<<"----------------"<<endl; delete translator; return 0; } 關(guān)于策略模式的討論
可以看到策略模式和 Template 模式解決了類似的問題，也正如在 Template 模式中分析的，策略模式和 Template 模式實(shí)際是實(shí)現(xiàn)一個(gè)抽象接口的兩種方式：繼承和組合之間的區(qū)別。要實(shí)現(xiàn)一個(gè)抽象接口，繼承是一種方式：我們將抽象接口聲明在基類中，將具體的實(shí)現(xiàn)放在具體子類中。組合（委托）是另外一種方式：我們將接口的實(shí)現(xiàn)放在被組合對(duì)象中，將抽象接口放在組合類中。這兩種方式各有優(yōu)缺點(diǎn)，先列出來：
1.繼承：
優(yōu)點(diǎn)：易于修改和擴(kuò)展那些被復(fù)用的實(shí)現(xiàn)。
缺點(diǎn)：①破壞了封裝性，繼承中父類的實(shí)現(xiàn)細(xì)節(jié)暴露給子類了；②"白盒"復(fù)用，原因在 1）中；③當(dāng)父類的實(shí)現(xiàn)更改時(shí)，其所有子類將不得不隨之改變；④從父類繼承而來的實(shí)現(xiàn)在運(yùn)行期間不能改變（編譯期間就已經(jīng)確定了）。
2.組合：
優(yōu)點(diǎn)：①"黑盒"復(fù)用，因?yàn)楸话瑢?duì)象的內(nèi)部細(xì)節(jié)對(duì)外是不可見的；②封裝性好，原因?yàn)?1）；③實(shí)現(xiàn)和抽象的依賴性很?。ńM合對(duì)象和被組合對(duì)象之間的依賴性小）；④可以在運(yùn)行期間動(dòng)態(tài)定義實(shí)現(xiàn)（通過一個(gè)指向相同類型的指針，典型的是抽象基類的指針）。
缺點(diǎn)：系統(tǒng)中對(duì)象過多。
從上面對(duì)比中我們可以看出，組合相比繼承可以取得更好的效果，因此在面向?qū)ο蟮脑O(shè)計(jì)中的有一條很重要的原則就是：優(yōu)先使用（對(duì)象）組合，而非（類）繼承（FavorComposition Over Inheritance）。
實(shí)際上，繼承是一種強(qiáng)制性很強(qiáng)的方式，因此也使得基類和具體子類之間的耦合性很強(qiáng)。例如在模板方法模式中在 ConcreteClass1 中定義的原語操作別的類是不能夠直接復(fù)用（除非你繼承自 AbstractClass，具體分析請(qǐng)參看模板方法模式文檔）。而組合（委托）的方式則有很小的耦合性，實(shí)現(xiàn)（具體實(shí)現(xiàn)）和接口（抽象接口）之間的依賴性很小，例如在本實(shí)現(xiàn)中，ConcreteStrategyA 的具體實(shí)現(xiàn)操作很容易被別的類復(fù)用，例如我們要定義另一個(gè) Context 類 AnotherContext，只要組合一個(gè)指向策略的指針就可以很容易地復(fù)用 ConcreteStrategyA 的實(shí)現(xiàn)了。
我們在 橋接模式的問題和橋接模式的分析中，正是說明了繼承和組合之間的區(qū)別。請(qǐng)參看相應(yīng)模式解析。
另外策略模式很狀態(tài)模式也有相似之處，但是狀態(tài)模式注重的對(duì)象在不同的狀態(tài)下不同的操作。兩者之間的區(qū)別就是狀態(tài)模式中具體實(shí)現(xiàn)類中有一個(gè)指向 Context的引用，而策略模式則沒有。具體分析請(qǐng)參看相應(yīng)的狀態(tài)模式分析中。
