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