策略模式（Strategy）：它定義了一系列的算法，并將每一個算法封裝起來，而且使它們還可以相互替換。策略模式讓算法的變化不會影響到使用算法的客戶。策略模式和 Template 模式要解決的問題是相同（類似）的，都是為了給業(yè)務(wù)邏輯（算法）具體實現(xiàn)和抽象接口之間的解耦。策略模式將邏輯（算法）封裝到一個類（Context）里面，通過組合的方式將具體算法的實現(xiàn)在組合對象中實現(xiàn)，再通過委托的方式將抽象接口的實現(xiàn)委托給組合對象實現(xiàn)。State 模式也有類似的功能，他們之間的區(qū)別將在討論中給出。

UML圖

優(yōu)點：
1、 簡化了單元測試，因為每個算法都有自己的類，可以通過自己的接口單獨測試。
2、 避免程序中使用多重條件轉(zhuǎn)移語句，使系統(tǒng)更靈活，并易于擴(kuò)展。
3、 遵守大部分GRASP原則和常用設(shè)計原則，高內(nèi)聚、低偶合。
缺點：
1、 因為每個具體策略類都會產(chǎn)生一個新類，所以會增加系統(tǒng)需要維護(hù)的類的數(shù)量。
2、 在基本的策略模式中，選擇所用具體實現(xiàn)的職責(zé)由客戶端對象承擔(dān)，并轉(zhuǎn)給策略模式的Context對象

實現(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的時候 
  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 模式實際是實現(xiàn)一個抽象接口的兩種方式：繼承和組合之間的區(qū)別。要實現(xiàn)一個抽象接口，繼承是一種方式：我們將抽象接口聲明在基類中，將具體的實現(xiàn)放在具體子類中。組合（委托）是另外一種方式：我們將接口的實現(xiàn)放在被組合對象中，將抽象接口放在組合類中。這兩種方式各有優(yōu)缺點，先列出來：
1.繼承：
優(yōu)點：易于修改和擴(kuò)展那些被復(fù)用的實現(xiàn)。
缺點：①破壞了封裝性，繼承中父類的實現(xiàn)細(xì)節(jié)暴露給子類了；②"白盒"復(fù)用，原因在 1）中；③當(dāng)父類的實現(xiàn)更改時，其所有子類將不得不隨之改變；④從父類繼承而來的實現(xiàn)在運行期間不能改變（編譯期間就已經(jīng)確定了）。
2.組合：
優(yōu)點：①"黑盒"復(fù)用，因為被包含對象的內(nèi)部細(xì)節(jié)對外是不可見的；②封裝性好，原因為 1）；③實現(xiàn)和抽象的依賴性很?。ńM合對象和被組合對象之間的依賴性小）；④可以在運行期間動態(tài)定義實現(xiàn)（通過一個指向相同類型的指針，典型的是抽象基類的指針）。
缺點：系統(tǒng)中對象過多。

從上面對比中我們可以看出，組合相比繼承可以取得更好的效果，因此在面向?qū)ο蟮脑O(shè)計中的有一條很重要的原則就是：優(yōu)先使用（對象）組合，而非（類）繼承（FavorComposition Over Inheritance）。

實際上，繼承是一種強制性很強的方式，因此也使得基類和具體子類之間的耦合性很強。例如在模板方法模式中在 ConcreteClass1 中定義的原語操作別的類是不能夠直接復(fù)用（除非你繼承自 AbstractClass，具體分析請參看模板方法模式文檔）。而組合（委托）的方式則有很小的耦合性，實現(xiàn)（具體實現(xiàn)）和接口（抽象接口）之間的依賴性很小，例如在本實現(xiàn)中，ConcreteStrategyA 的具體實現(xiàn)操作很容易被別的類復(fù)用，例如我們要定義另一個 Context 類 AnotherContext，只要組合一個指向策略的指針就可以很容易地復(fù)用 ConcreteStrategyA 的實現(xiàn)了。

我們在 橋接模式的問題和橋接模式的分析中，正是說明了繼承和組合之間的區(qū)別。請參看相應(yīng)模式解析。

另外策略模式很狀態(tài)模式也有相似之處，但是狀態(tài)模式注重的對象在不同的狀態(tài)下不同的操作。兩者之間的區(qū)別就是狀態(tài)模式中具體實現(xiàn)類中有一個指向 Context的引用，而策略模式則沒有。具體分析請參看相應(yīng)的狀態(tài)模式分析中。