|
|
算法與對象的耦合
對象可能經常需要使用多種不同的算法，但是如果變化頻繁，會將類型變得脆弱……
動機（Motivation）
在軟件構建過程中，某些對象使用的算法可能多種多樣，經常改變，如果將這些算法都編碼到對象中，將會使對象變得異常復雜；而且有時候支持不使用的算法也是一個性能負擔。如何在運行時根據需要透明地更改對象的算法？將算法與對象本身解耦，從而避免上述問題？
意圖（Intent）
定義一系列算法，把它們一個個封裝起來，并且使它們可互相替換。該模式使得算法可獨立于使用它的客戶而變化。
——《設計模式》GoF
例說Strategy模式應用
這個程序有兩個可能的變化點：當枚舉類型增加時，即處理的方法增加，那么Process函數需要修改補充一個if else分支；當我們想對分支1的處理ProcessA進行更改時，也要對Process函數進行修改。針對上面的問題，我們首先想到的是把ProcessA寫成受保護的虛函數（在OO中我們一般把虛函數都寫成受保護的函數，因為它是能改變類的行為的函數，一般情況下只應該作為子類和父類之間的協議出現）。
Strategy模式的設計
把Cart類和ProcessStrategy類作為對象組合的方式使用。IProcessStrategy表達的是一個算法抽象。
抽象和具體算法
客戶程序
這樣算法就可以動態(tài)地去改變了，我們動態(tài)地去new一組具體的Process算法，然后提供給Cart類使用。delegate只要符合參數和返回值，不管是靜態(tài)方法或者是抽象方法，就可以動態(tài)地掛上。但是接口需要抽象含義一致，因此對于這個模式更推薦使用接口來表達抽象的算法。
結構（Structure）
算法并不是孤立的，它通常都需要有一些上下文去調用它，或者是傳入一些參數。Strategy類型里面不攜帶狀態(tài)信息（這是與模板方法的區(qū)別，模板方法本身是攜帶狀態(tài)信息的），我們不能把它看成一種實例，即使有狀態(tài)，也是會通過參數傳入。一個Strategy定義了一個算法的完整步驟和結構，只要用一個Strategy具體類，就可以完成整個算法的操作，不會有其它依賴和耦合。Context和Strategy是一個對象組合的使用關系。Strategy中的抽象接口隨時可以替換成具體的類，達到在不同算法之間動態(tài)地切換。
這個模式的核心是通過對象組合的方式把本來直接調用的內容委托給接口實體對象來完成，至于接口實體對象具體是什么，在運行時才知道，即是運行時改變。
Strategy模式的幾個要點
Strategy及其子類為組件提供了一系列可重用的算法，從而可以使得類型在運行時方便地根據需要在各個算法之間進行切換，所謂封裝算法，支持算法的變化。Strategy模式提供了用條件判斷語句以外的另一種選擇，消除條件判斷語句，就是在解耦合。含有許多條件判斷語句的代碼通常都需要Strategy模式。
與State類似，如果Strategy對象沒有實例變量，那么各個上下文可以共享一個Strategy對象，從而節(jié)省對象開銷。Strategy模式適用的是算法結構中整個算法的改變，而不是算法中某個部分的改變。
Template Method方法：執(zhí)行算法的步驟協議是本身放在抽象類里面的，允許一個通用的算法操作多個可能實現
Strategy模式：執(zhí)行算法的協議是在具體類，每個具體實現有不同通用算法來做。
例如ArrayList類，Sort方法做不了什么事情，因為Point類不支持排序，沒有繼承IComparer接口。
但如果我們想支持排序，其實Sort方法就是一個Strategy模式，它支持傳入一個繼承IComparer接口的具體類。
IComparer接口其實就是Strategy我們上面例子中的IProcessStrategy。我們可以實現一個IComparer接口，然后把具體類傳入，這樣Sort方法就會按我們定義的排序規(guī)則執(zhí)行了。
當我們需要切換排序方法的時候，只需要更改傳入Sort的具體比較類即可。
ArrayList雖然沒有把排序方法作為字段組合，但是它把它作為參數來使用了。因為比較不是在ArrayList中大多數方法都使用，只有排序才需要使用，所以把它作為參數使用更合適。
it知識庫：C#面向對象設計模式縱橫談：Strategy 策略模式，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
