名稱	Strategy
結(jié)構(gòu)
意圖	定義一系列的算法,把它們一個(gè)個(gè)封裝起來(lái), 并且使它們可相互替換。本模式使得算法可獨(dú)立于使用它的客戶而變化。
適用性	許多相關(guān)的類僅僅是行為有異。“策略”提供了一種用多個(gè)行為中的一個(gè)行為來(lái)配置一個(gè)類的方法。 需要使用一個(gè)算法的不同變體。例如，你可能會(huì)定義一些反映不同的空間/時(shí)間權(quán)衡的算法。當(dāng)這些變體實(shí)現(xiàn)為一個(gè)算法的類層次時(shí)[ H O 8 7 ] ,可以使用策略模式。 算法使用客戶不應(yīng)該知道的數(shù)據(jù)。可使用策略模式以避免暴露復(fù)雜的、與算法相關(guān)的數(shù)據(jù)結(jié)構(gòu)。 一個(gè)類定義了多種行為, 并且這些行為在這個(gè)類的操作中以多個(gè)條件語(yǔ)句的形式出現(xiàn)。將相關(guān)的條件分支移入它們各自的S t r a t e g y 類中以代替這些條件語(yǔ)句。

namespace ?Strategy_DesignPattern
{
???? using ?System;

????
???? abstract ? class ?Strategy?
???? {
???????? abstract ? public ? void ?DoAlgorithm();
????}

???? class ?FirstStrategy?:?Strategy?
???? {
???????? override ? public ? void ?DoAlgorithm()
???????? {
????????????Console.WriteLine( " In?first?strategy " );????????????
????????}
????}

???? class ?SecondStrategy?:?Strategy?
???? {
???????? override ? public ? void ?DoAlgorithm()
???????? {
????????????Console.WriteLine( " In?second?strategy " );????????????
????????}
????}

???? class ?Context?
???? {
????????Strategy?s;
???????? public ?Context(Strategy?strat)
???????? {
????????????s? = ?strat;????????????
????????}

???????? public ? void ?DoWork()
???????? {
???????????? // ?some?of?the?context's?own?code?goes?here
????????}

???????? public ? void ?DoStrategyWork()
???????? {
???????????? // ?now?we?can?hand?off?to?the?strategy?to?do?some?
???????????? // ?more?work
????????????s.DoAlgorithm();
????????}
????}

???? /**/ /// ? <summary>
???? /// ????Summary?description?for?Client.
???? /// ? </summary>
???? public ? class ?Client
???? {
???????? public ? static ? int ?Main( string []?args)
???????? {????
????????????FirstStrategy?firstStrategy? = ? new ?FirstStrategy();
????????????Context?c? = ? new ?Context(firstStrategy);
????????????c.DoWork();
????????????c.DoStrategyWork();

???????????? return ? 0 ;
????????}
????}
}

一、?策略（Strategy）模式

策略模式的用意是針對(duì)一組算法，將每一個(gè)算法封裝到具有共同接口的獨(dú)立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發(fā)生變化。

假設(shè)現(xiàn)在要設(shè)計(jì)一個(gè)販賣各類書籍的電子商務(wù)網(wǎng)站的購(gòu)物車（Shopping Cat）系統(tǒng)。一個(gè)最簡(jiǎn)單的情況就是把所有貨品的單價(jià)乘上數(shù)量，但是實(shí)際情況肯定比這要復(fù)雜。比如，本網(wǎng)站可能對(duì)所有的教材類圖書實(shí)行每本一元的折扣；對(duì)連環(huán)畫類圖書提供每本7％的促銷折扣，而對(duì)非教材類的計(jì)算機(jī)圖書有3％的折扣；對(duì)其余的圖書沒(méi)有折扣。由于有這樣復(fù)雜的折扣算法，使得價(jià)格計(jì)算問(wèn)題需要系統(tǒng)地解決。

使用策略模式可以把行為和環(huán)境分割開來(lái)。環(huán)境類負(fù)責(zé)維持和查詢行為類，各種算法則在具體策略類（ConcreteStrategy）中提供。由于算法和環(huán)境獨(dú)立開來(lái)，算法的增減、修改都不會(huì)影響環(huán)境和客戶端。當(dāng)出現(xiàn)新的促銷折扣或現(xiàn)有的折扣政策出現(xiàn)變化時(shí)，只需要實(shí)現(xiàn)新的策略類，并在客戶端登記即可。策略模式相當(dāng)于"可插入式（Pluggable）的算法"。
?何時(shí)使用何種具體策略角色

在學(xué)習(xí)策略模式時(shí)，學(xué)員常問(wèn)的一個(gè)問(wèn)題是：為什么不能從策略模式中看出哪一個(gè)具體策略適用于哪一種情況呢？

答案非常簡(jiǎn)單，策略模式并不負(fù)責(zé)做這個(gè)決定。換言之，應(yīng)當(dāng)由客戶端自己決定在什么情況下使用什么具體策略角色。策略模式僅僅封裝算法，提供新算法插入到已有系統(tǒng)中，以及老算法從系統(tǒng)中"退休"的方便，策略模式并不決定在何時(shí)使用何種算法。
sort()很好的例子:

// ?Strategy?pattern?--?Real?World?example??
using ?System;
using ?System.Collections;

// ?"Strategy"
abstract ? class ?SortStrategy
{
?? // ?Methods
?? abstract ? public ? void ?Sort(?ArrayList?list?);
}

// ?"ConcreteStrategy"
class ?QuickSort?:?SortStrategy
{
?? // ?Methods
?? public ? override ? void ?Sort(ArrayList?list?)
?? {
????list.Sort();? // ?Default?is?Quicksort
????Console.WriteLine( " QuickSorted?list? " );
??}
}

// ?"ConcreteStrategy"
class ?ShellSort?:?SortStrategy
{
?? // ?Methods
?? public ? override ? void ?Sort(ArrayList?list?)
?? {
???? // list.ShellSort();
????Console.WriteLine( " ShellSorted?list? " );
??}
}

// ?"ConcreteStrategy"
class ?MergeSort?:?SortStrategy
{
?? // ?Methods
?? public ? override ? void ?Sort(?ArrayList?list?)
?? {
???? // list.MergeSort();
????Console.WriteLine( " MergeSorted?list? " );
??}
}

// ?"Context"
class ?SortedList
{
?? // ?Fields
?? private ?ArrayList?list? = ? new ?ArrayList();
?? private ?SortStrategy?sortstrategy;

?? // ?Constructors
?? public ? void ?SetSortStrategy(?SortStrategy?sortstrategy?)
?? {
???? this .sortstrategy? = ?sortstrategy;
??}

?? // ?Methods
?? public ? void ?Sort()
?? {
????sortstrategy.Sort(?list?);
??}

?? public ? void ?Add(? string ?name?)
?? {
????list.Add(?name?);
??}

?? public ? void ?Display()
?? {
???? foreach (? string ?name? in ?list?)
??????Console.WriteLine(? " ? " ? + ?name?);
??}
}

/**/ /**/ /**/ /// ? <summary>
/// ?StrategyApp?test
/// ? </summary>
public ? class ?StrategyApp
{
?? public ? static ? void ?Main(? string []?args?)
?? {
???? // ?Two?contexts?following?different?strategies
????SortedList?studentRecords? = ? new ?SortedList(?);
????studentRecords.Add(? " Samual " ?);
????studentRecords.Add(? " Jimmy " ?);
????studentRecords.Add(? " Sandra " ?);
????studentRecords.Add(? " Anna " ?);
????studentRecords.Add(? " Vivek " ?);

????studentRecords.SetSortStrategy(? new ?QuickSort()?);
????studentRecords.Sort();
????studentRecords.Display();
??}
}

六、?在什么情況下應(yīng)當(dāng)使用策略模式

在下面的情況下應(yīng)當(dāng)考慮使用策略模式：

1.?如果在一個(gè)系統(tǒng)里面有許多類，它們之間的區(qū)別僅在于它們的行為，那么使用策略模式可以動(dòng)態(tài)地讓一個(gè)對(duì)象在許多行為中選擇一種行為。

2.?一個(gè)系統(tǒng)需要?jiǎng)討B(tài)地在幾種算法中選擇一種。那么這些算法可以包裝到一個(gè)個(gè)的具體算法類里面，而這些具體算法類都是一個(gè)抽象算法類的子類。換言之，這些具體算法類均有統(tǒng)一的接口，由于多態(tài)性原則，客戶端可以選擇使用任何一個(gè)具體算法類，并只持有一個(gè)數(shù)據(jù)類型是抽象算法類的對(duì)象。

3.?一個(gè)系統(tǒng)的算法使用的數(shù)據(jù)不可以讓客戶端知道。策略模式可以避免讓客戶端涉及到不必要接觸到的復(fù)雜的和只與算法有關(guān)的數(shù)據(jù)。

4.?如果一個(gè)對(duì)象有很多的行為，如果不用恰當(dāng)?shù)哪Ｊ剑@些行為就只好使用多重的條件選擇語(yǔ)句來(lái)實(shí)現(xiàn)。此時(shí)，使用策略模式，把這些行為轉(zhuǎn)移到相應(yīng)的具體策略類里面，就可以避免使用難以維護(hù)的多重條件選擇語(yǔ)句，并體現(xiàn)面向?qū)ο笤O(shè)計(jì)的概念。

七、?策略模式的優(yōu)點(diǎn)和缺點(diǎn)

策略模式有很多優(yōu)點(diǎn)和缺點(diǎn)。它的優(yōu)點(diǎn)有：

1.?策略模式提供了管理相關(guān)的算法族的辦法。策略類的等級(jí)結(jié)構(gòu)定義了一個(gè)算法或行為族。恰當(dāng)使用繼承可以把公共的代碼移到父類里面，從而避免重復(fù)的代碼。

2.?策略模式提供了可以替換繼承關(guān)系的辦法。繼承可以處理多種算法或行為。如果不是用策略模式，那么使用算法或行為的環(huán)境類就可能會(huì)有一些子類，每一個(gè)子類提供一個(gè)不同的算法或行為。但是，這樣一來(lái)算法或行為的使用者就和算法或行為本身混在一起。決定使用哪一種算法或采取哪一種行為的邏輯就和算法或行為的邏輯混合在一起，從而不可能再獨(dú)立演化。繼承使得動(dòng)態(tài)改變算法或行為變得不可能。

3.?使用策略模式可以避免使用多重條件轉(zhuǎn)移語(yǔ)句。多重轉(zhuǎn)移語(yǔ)句不易維護(hù)，它把采取哪一種算法或采取哪一種行為的邏輯與算法或行為的邏輯混合在一起，統(tǒng)統(tǒng)列在一個(gè)多重轉(zhuǎn)移語(yǔ)句里面，比使用繼承的辦法還要原始和落后。

策略模式的缺點(diǎn)有：

1.?客戶端必須知道所有的策略類，并自行決定使用哪一個(gè)策略類。這就意味著客戶端必須理解這些算法的區(qū)別，以便適時(shí)選擇恰當(dāng)?shù)乃惴悺Q言之，策略模式只適用于客戶端知道所有的算法或行為的情況。

2.?策略模式造成很多的策略類。有時(shí)候可以通過(guò)把依賴于環(huán)境的狀態(tài)保存到客戶端里面，而將策略類設(shè)計(jì)成可共享的，這樣策略類實(shí)例可以被不同客戶端使用。換言之，可以使用享元模式來(lái)減少對(duì)象的數(shù)量。

八、?其它

策略模式與很多其它的模式都有著廣泛的聯(lián)系。Strategy很容易和Bridge模式相混淆。雖然它們結(jié)構(gòu)很相似，但它們卻是為解決不同的問(wèn)題而設(shè)計(jì)的。Strategy模式注重于算法的封裝，而Bridge模式注重于分離抽象和實(shí)現(xiàn)，為一個(gè)抽象體系提供不同的實(shí)現(xiàn)。Bridge模式與Strategy模式都很好的體現(xiàn)了"Favor composite over inheritance"的觀點(diǎn)。