詳解C++設計形式編程中戰略形式的優缺陷及完成

詳解C++設計形式編程中戰略形式的優缺陷及完成。本站提示廣大學習愛好者：（詳解C++設計形式編程中戰略形式的優缺陷及完成）文章只能為提供參考，不一定能成為您想要的結果。以下是詳解C++設計形式編程中戰略形式的優缺陷及完成正文

戰略形式（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的援用，而戰略形式則沒有。詳細剖析請參看響應的狀況形式剖析中。