設計模式策略模式

不要問我為何要給對策略模式單寫一篇部落格，在《大話設計模式》中介紹的第二個設計模式，就是「策略模式」，什麼時候用到策略模式，在書中介紹了這樣乙個場景：你需要給某超市設計乙個結帳系統，該系統需要對使用者選擇的商品進行一定的優惠計算，並最終得到結算**；這些優惠可能是買五送一，可以是滿100打八折等等。此時用策略模式的目的，則是將這些優惠演算法進行封裝，並通過封裝後的context類，動態選擇優惠演算法，得到最後金額。

先看下優惠演算法的基類介面

public inte***ce istrategy

下面是幾個優惠演算法的基類實現

public class strategy_a implements istrategy }public class strategy_b implements istrategy }public class strategy_c implements istrategy

}

接下來是我們高潮部分，策略模式的精華所在，用於抽象出所有封裝演算法的環境類，該類可以動態的選擇演算法實現，並得到運算結果：

istrategy strategy = null;
public
context(string func) 
}public
void
getcash()

雖然我寫的非常簡單，但是還是要做個樣子假裝講解一下：構造方法中「string func」引數是用於實現演算法選擇的依據。其中對於演算法選擇的模組，可以結合簡單工廠設計模式來實現。

下面是程式入口：

public
class
testmain 
}

執行結果如下：

this is a strategy mode

這個是方法a

這個是方法b

這個是方法c

其實在上面context類的**中，聰明如你，應該也能看出來，使用這種策略模式，客戶必須對每種策略（即上面場景中的優惠演算法）心知肚明。並且需要將相關引數傳入context構造方法，才能獲取相應的策略物件。同時，如果有了優惠策略有了變動，那麼我們的context類也要做出相應的修改——新增或修改stategy（策略子類），事實上，這與程式設計中封閉開放原則（對改動封閉，對擴充套件開放）有所背離。

當然，好處也是顯而易見的，你可以只用乙個context物件，就可以得到最終的結果，相比於使用不同的stategy子類物件，操作成本得到了簡化！

設計模式 策略模式

設計模式 策略設計模式

設計模式 策略模式

設計模式 策略模式

相關推薦

設計模式策略模式

設計模式策略設計模式

設計模式策略模式

設計模式策略模式