原文轉(zhuǎn)自：http://www.cnblogs.com/zhenyulu/articles/82017.html
原作者：呂震宇
PS：原作是C#版的，本人將其譯成Java，有少許改動。
一、 策略（Strategy）模式
策略模式的用意是針對一組算法，將每一個算法封裝到具有共同接口的獨(dú)立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發(fā)生變化。
假設(shè)現(xiàn)在要設(shè)計(jì)一個販賣各類書籍的電子商務(wù)網(wǎng)站的購物車（Shopping Cat）系統(tǒng)。一個最簡單的情況就是把所有貨品的單價(jià)乘上數(shù)量，但是實(shí)際情況肯定比這要復(fù)雜。比如，本網(wǎng)站可能對所有的教材類圖書實(shí)行每本一元的折扣；對連環(huán)畫類圖書提供每本7％的促銷折扣，而對非教材類的計(jì)算機(jī)圖書有3％的折扣；對其余的圖書沒有折扣。由于有這樣復(fù)雜的折扣算法，使得價(jià)格計(jì)算問題需要系統(tǒng)地解決。
使用策略模式可以把行為和環(huán)境分割開來。環(huán)境類負(fù)責(zé)維持和查詢行為類，各種算法則在具體策略類（ConcreteStrategy）中提供。由于算法和環(huán)境獨(dú)立開來，算法的增減、修改都不會影響環(huán)境和客戶端。當(dāng)出現(xiàn)新的促銷折扣或現(xiàn)有的折扣政策出現(xiàn)變化時，只需要實(shí)現(xiàn)新的策略類，并在客戶端登記即可。策略模式相當(dāng)于"可插入式（Pluggable）的算法"。
二、 策略模式的結(jié)構(gòu)
策略模式是對算法的包裝，是把使用算法的責(zé)任和算法本身分割開，委派給不同的對象管理。策略模式通常把一個系列的算法包裝到一系列的策略類里面，作為一個抽象策略類的子類。用一句話來說，就是："準(zhǔn)備一組算法，并將每一個算法封裝起來，使得它們可以互換。"
策略又稱做政策（Policy）模式【GOF95】。下面是一個示意性的策略模式結(jié)構(gòu)圖：
這個模式涉及到三個角色：
* 環(huán)境（Context）角色：持有一個Strategy類的引用。
* 抽象策略（Strategy）角色：這是一個抽象角色，通常由一個接口或抽象類實(shí)現(xiàn)。此角色給出所有的具體策略類所需的接口。
* 具體策略（ConcreteStrategy）角色：包裝了相關(guān)的算法或行為。
三、 示意性源代碼
//抽象策略
abstract class Strategy {
public abstract void AlgorithmInterface();
}
//具體的策略算法A
class ConcreteStrategyA extends Strategy{
@Override public void AlgorithmInterface(){
System.out.println ("使用策略A");
}
}
//具體的策略算法B
class ConcreteStrategyB extends Strategy{
@Override public void AlgorithmInterface(){
System.out.println ("使用策略B");
}
}
//環(huán)境
class Context{
Strategy strategy;
public Context(Strategy strategy){
this.strategy = strategy;
}
public void contextInterface(){
strategy.AlgorithmInterface();
}
//改變策略
public void setStratery(Strategy strategy){
this.strategy = strategy;
}
}
//測試
public class Client{
public static void main (String[] args) {
Context c = new Context(new ConcreteStrategyA());
c.contextInterface();
//可以很方便地改變策略，而不必修改原來的代碼
c.setStratery(new ConcreteStrategyB());
c.contextInterface();
}
}
/*輸出：
使用策略A
使用策略B
*/
四、 何時使用何種具體策略角色
在學(xué)習(xí)策略模式時，學(xué)員常問的一個問題是：為什么不能從策略模式中看出哪一個具體策略適用于哪一種情況呢？
答案非常簡單，策略模式并不負(fù)責(zé)做這個決定。換言之，應(yīng)當(dāng)由客戶端自己決定在什么情況下使用什么具體策略角色。策略模式僅僅封裝算法，提供新算法插入到已有系統(tǒng)中，以及老算法從系統(tǒng)中"退休"的方便，策略模式并不決定在何時使用何種算法。
五、 一個實(shí)際應(yīng)用策略模式的例子
下面的例子利用策略模式在排序?qū)ο笾蟹庋b了不同的排序算法，這樣以便允許客戶端動態(tài)的替換排序策略（包括Quicksort、Shellsort和Mergesort）。
import java.util.ArrayList;
//抽排序象策略
abstract class SortStrategy{
abstract public void sort(ArrayList list);
}
//快排策略
class QuickSort extends SortStrategy{
@Override public void sort(ArrayList list){
System.out.println ("QuickSorted list");
}
}
//希爾排序策略
class ShellSort extends SortStrategy{
@Override public void sort(ArrayList list){
System.out.println ("ShellSorted list");
}
}
//歸并排序策略
class MergeSort extends SortStrategy{
@Override public void sort(ArrayList list){
System.out.println ("MergeSort list");
}
}
//環(huán)境
class SortedList{
private ArrayList list = new ArrayList();
private SortStrategy sortStrategy;
public SortedList(SortStrategy sortStrategy){
this.sortStrategy = sortStrategy;
}
public void sort(){
sortStrategy.sort(list);
}
//改變策略
public void setStrategy(SortStrategy sortStrategy){
this.sortStrategy = sortStrategy;
}
}
//測試
public class StrategyApp {
public static void main (String[] args) {
SortedList studentRecords = new SortedList(new QuickSort());
studentRecords.sort();
//改用希爾排序
studentRecords.setStrategy(new ShellSort());
studentRecords.sort();
}
}
/*輸出：
QuickSorted list
ShellSorted list
*/
六、 在什么情況下應(yīng)當(dāng)使用策略模式
在下面的情況下應(yīng)當(dāng)考慮使用策略模式：
1. 如果在一個系統(tǒng)里面有許多類，它們之間的區(qū)別僅在于它們的行為，那么使用策略模式可以動態(tài)地讓一個對象在許多行為中選擇一種行為。
2. 一個系統(tǒng)需要動態(tài)地在幾種算法中選擇一種。那么這些算法可以包裝到一個個的具體算法類里面，而這些具體算法類都是一個抽象算法類的子類。換言之，這些具體算法類均有統(tǒng)一的接口，由于多態(tài)性原則，客戶端可以選擇使用任何一個具體算法類，并只持有一個數(shù)據(jù)類型是抽象算法類的對象。
3. 一個系統(tǒng)的算法使用的數(shù)據(jù)不可以讓客戶端知道。策略模式可以避免讓客戶端涉及到不必要接觸到的復(fù)雜的和只與算法有關(guān)的數(shù)據(jù)。
4. 如果一個對象有很多的行為，如果不用恰當(dāng)?shù)哪Ｊ剑@些行為就只好使用多重的條件選擇語句來實(shí)現(xiàn)。此時，使用策略模式，把這些行為轉(zhuǎn)移到相應(yīng)的具體策略類里面，就可以避免使用難以維護(hù)的多重條件選擇語句，并體現(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)的算法族的辦法。策略類的等級結(jié)構(gòu)定義了一個算法或行為族。恰當(dāng)使用繼承可以把公共的代碼移到父類里面，從而避免重復(fù)的代碼。
2. 策略模式提供了可以替換繼承關(guān)系的辦法。繼承可以處理多種算法或行為。如果不是用策略模式，那么使用算法或行為的環(huán)境類就可能會有一些子類，每一個子類提供一個不同的算法或行為。但是，這樣一來算法或行為的使用者就和算法或行為本身混在一起。決定使用哪一種算法或采取哪一種行為的邏輯就和算法或行為的邏輯混合在一起，從而不可能再獨(dú)立演化。繼承使得動態(tài)改變算法或行為變得不可能。
3. 使用策略模式可以避免使用多重條件轉(zhuǎn)移語句。多重轉(zhuǎn)移語句不易維護(hù)，它把采取哪一種算法或采取哪一種行為的邏輯與算法或行為的邏輯混合在一起，統(tǒng)統(tǒng)列在一個多重轉(zhuǎn)移語句里面，比使用繼承的辦法還要原始和落后。
策略模式的缺點(diǎn)有：
1. 客戶端必須知道所有的策略類，并自行決定使用哪一個策略類。這就意味著客戶端必須理解這些算法的區(qū)別，以便適時選擇恰當(dāng)?shù)乃惴悺Q言之，策略模式只適用于客戶端知道所有的算法或行為的情況。
2. 策略模式造成很多的策略類。有時候可以通過把依賴于環(huán)境的狀態(tài)保存到客戶端里面，而將策略類設(shè)計(jì)成可共享的，這樣策略類實(shí)例可以被不同客戶端使用。換言之，可以使用享元模式來減少對象的數(shù)量。
八、 其它
策略模式與很多其它的模式都有著廣泛的聯(lián)系。Strategy很容易和Bridge模式相混淆。雖然它們結(jié)構(gòu)很相似，但它們卻是為解決不同的問題而設(shè)計(jì)的。 Strategy模式注重于算法的封裝，而Bridge模式注重于分離抽象和實(shí)現(xiàn)，為一個抽象體系提供不同的實(shí)現(xiàn)。Bridge模式與Strategy模式都很好的體現(xiàn)了"Favor composite over inheritance"的觀點(diǎn)。
推薦大家讀一讀《IoC 容器和Dependency Injection 模式》，作者M(jìn)artin Fowler。網(wǎng)上可以找到中文版的PDF文件。為策略模式的實(shí)施提供了一個非常好的方案。
參考文獻(xiàn)：
閻宏，《Java與模式》，電子工業(yè)出版社
[美]James W. Cooper，《C#設(shè)計(jì)模式》，電子工業(yè)出版社
[美]Alan Shalloway James R. Trott，《Design Patterns Explained》，中國電力出版社
[美]Robert C. Martin，《敏捷軟件開發(fā)－原則、模式與實(shí)踐》，清華大學(xué)出版社
[美]Don Box, Chris Sells，《.NET本質(zhì)論 第1卷：公共語言運(yùn)行庫》，中國電力出版社