策略模式，又稱政策模式，一種對象行為型模式。定義一系列算法，把他們用一個個類封裝起來，并使它們可以相互替換。該模式中使得算法可以獨立于使用與使用它的客戶程序中。

實現(xiàn)方式是：類的繼承和多態(tài)的形式創(chuàng)建對象

例如，在算法實現(xiàn)中要根據(jù)情況不同而走不同的分支，各個分支都是做相同的算法但是又各個獨立。

例如，關于計算稅收的一個方法，要支持中國、日本、美國的稅務計算，有如下兩種實現(xiàn)方式

enum countryType{CN,US,JP } class ctax{ public: countryType type; int caltax (Object param){switch(type){case CN://中國的稅務計算break;case US://美國的稅務計算break;case JP://日本的稅務計算break;default：.....}}

第二種：

class taxStrategy{virtual int caltax (Object param)=0; } class cnTaxStrategy:pubilc taxStrategy{virtual int caltax (Object param){/**中國的稅務計算**/}; } class usTaxStrategy:pubilc taxStrategy{ countryType type;virtual int caltax (Object param){/**美國的稅務計算**/}; } class jpTaxStrategy:pubilc taxStrategy{ countryType type;virtual int caltax (Object param){/**日本的稅務計算**/}; }class ctax{ public: countryType type; int caltax (Object param){taxStrategy* strategy = newStrategy(); //創(chuàng)建實體strategy->caltax(param) ; }

在這兩種例子中客戶的應用程序是ctax。假如有一個需求“新增英國稅收的算法”，那么第一種代碼，就要新增枚舉，延長switch...case..的實現(xiàn)方式。而第二種方式需要新創(chuàng)建一個派生類且擴展對象實例化方法newStrategy()。

雖然在功能上需求上，兩者方法都可以實現(xiàn)。但是從可維護性來講，無疑第一種方式是比較差的。假如算法復雜度過高，或者將來又有擴展不同國家稅收需求。那么第一種方法實現(xiàn)起來代碼量就會很大，誤操作引發(fā)的生產(chǎn)事故的概率就會變大。從可復用性來講，假如其他項目需要復用稅收的代碼，那么第一種方式只能是Ctrl CV，而第二種方式實現(xiàn)了算法和應用程序的分離，對于算法變更不會影響到客戶程序ctax。又例如，把這套程序提供給中國的用戶，該中國用戶只需要中國的稅收算法，不需要支持其他國家稅收。那么第一種方式就會不可避免的將大量的無用算法代碼編譯進工程中，降低性能。

所以,每當當使用if...elseif... 或者 switch...case 就要考慮到是否策略模式更適合。當然，對于可窮舉的條件判斷 if...elseif..是合適的，例如性別，月份。但是對于不可窮舉的條件判斷或者判斷條件會根據(jù)業(yè)務需求變化的時候就需要進行特別的考慮。策略模式最主要的目的是為了新增業(yè)務需求時 減少代碼開發(fā)、維護、測試工作量、減小新需求涉及到的影響范圍。

?

總結

以上是生活随笔為你收集整理的设计模式理解：策略模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。