策略模式（Strategy）：它定義了一系列的算法，并將每一個算法封裝起來，而且使它們還可以相互替換。策略模式讓算法的變化不會影響到使用算法的客戶。策略模式和 Template 模式要解決的問題是相同（類似）的，都是為了給業務邏輯（算法）具體實現和抽象接口之間的解耦。策略模式將邏輯（算法）封裝到一個類（Context）里面，通過組合的方式將具體算法的實現在組合對象中實現，再通過委托的方式將抽象接口的實現委托給組合對象實現。State 模式也有類似的功能，他們之間的區別將在討論中給出。
UML圖
優點：
1、 簡化了單元測試，因為每個算法都有自己的類，可以通過自己的接口單獨測試。
2、 避免程序中使用多重條件轉移語句，使系統更靈活，并易于擴展。
3、 遵守大部分GRASP原則和常用設計原則，高內聚、低偶合。
缺點：
1、 因為每個具體策略類都會產生一個新類，所以會增加系統需要維護的類的數量。
2、 在基本的策略模式中，選擇所用具體實現的職責由客戶端對象承擔，并轉給策略模式的Context對象
實現示例：
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的時候 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; } 關于策略模式的討論
可以看到策略模式和 Template 模式解決了類似的問題，也正如在 Template 模式中分析的，策略模式和 Template 模式實際是實現一個抽象接口的兩種方式：繼承和組合之間的區別。要實現一個抽象接口，繼承是一種方式：我們將抽象接口聲明在基類中，將具體的實現放在具體子類中。組合（委托）是另外一種方式：我們將接口的實現放在被組合對象中，將抽象接口放在組合類中。這兩種方式各有優缺點，先列出來：
1.繼承：
優點：易于修改和擴展那些被復用的實現。
缺點：①破壞了封裝性，繼承中父類的實現細節暴露給子類了；②"白盒"復用，原因在 1）中；③當父類的實現更改時，其所有子類將不得不隨之改變；④從父類繼承而來的實現在運行期間不能改變（編譯期間就已經確定了）。
2.組合：
優點：①"黑盒"復用，因為被包含對象的內部細節對外是不可見的；②封裝性好，原因為 1）；③實現和抽象的依賴性很小（組合對象和被組合對象之間的依賴性?。?；④可以在運行期間動態定義實現（通過一個指向相同類型的指針，典型的是抽象基類的指針）。
缺點：系統中對象過多。
從上面對比中我們可以看出，組合相比繼承可以取得更好的效果，因此在面向對象的設計中的有一條很重要的原則就是：優先使用（對象）組合，而非（類）繼承（FavorComposition Over Inheritance）。
實際上，繼承是一種強制性很強的方式，因此也使得基類和具體子類之間的耦合性很強。例如在模板方法模式中在 ConcreteClass1 中定義的原語操作別的類是不能夠直接復用（除非你繼承自 AbstractClass，具體分析請參看模板方法模式文檔）。而組合（委托）的方式則有很小的耦合性，實現（具體實現）和接口（抽象接口）之間的依賴性很小，例如在本實現中，ConcreteStrategyA 的具體實現操作很容易被別的類復用，例如我們要定義另一個 Context 類 AnotherContext，只要組合一個指向策略的指針就可以很容易地復用 ConcreteStrategyA 的實現了。
我們在 橋接模式的問題和橋接模式的分析中，正是說明了繼承和組合之間的區別。請參看相應模式解析。
另外策略模式很狀態模式也有相似之處，但是狀態模式注重的對象在不同的狀態下不同的操作。兩者之間的區別就是狀態模式中具體實現類中有一個指向 Context的引用，而策略模式則沒有。具體分析請參看相應的狀態模式分析中。
