在閻宏博士的《Java與模式》一書中開頭是這樣描述策略（Strategy）模式的：
策略模式屬于對象的行為模式。其用意是針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發生變化。
策略模式的結構
策略模式是對算法的包裝，是把使用算法的責任和算法本身分割開來，委派給不同的對象管理。策略模式通常把一個系列的算法包裝到一系列的策略類里面，作為一個抽象策略類的子類。用一句話來說，就是：“準備一組算法，并將每一個算法封裝起來，使得它們可以互換”。下面就以一個示意性的實現講解策略模式實例的結構。
這個模式涉及到三個角色：
環境(Context)角色：持有一個Strategy的引用。
抽象策略(Strategy)角色：這是一個抽象角色，通常由一個接口或抽象類實現。此角色給出所有的具體策略類所需的接口。
具體策略(ConcreteStrategy)角色：包裝了相關的算法或行為。
環境角色類
/**
* 環境角色，持有Strategy的引用
*/
public class StrategyContext {
private Strategy strategy;
/**
* 構造函數傳入具體的Strategy實現類
* @param strategy
*/
public StrategyContext(Strategy strategy){
this.strategy = strategy;
}
/**
* 策略方法
*/
public void contextDo(){
strategy.doMath();
}
}
抽象策略類
/**
* 抽象的策略類
*/
public interface Strategy {
/**
* 抽象的側路方法
*/
public abstract void doMath();
}
具體策略類
public class ConcreteStrategyAdd implements Strategy {
/**
* 完成具體的算法
*/
public void doMath() {
System.out.println("doAdd");
}
}
public class ConcreteStrategySub implements Strategy {
/**
* 完成具體的算法
*/
public void doMath() {
System.out.println("doSub");
}
}
客戶端代碼)客戶端代碼
public class TestMain {
public static void main(String[] args) {
ConcreteStrategyAdd add = new ConcreteStrategyAdd();
StrategyContext context = new StrategyContext(add);
context.contextDo();
}
}
從上面的示例可以看出，策略模式僅僅封裝算法，提供新的算法插入到已有系統中，以及老算法從系統中“退休”的方法，策略模式并不決定在何時使用何種算法。在什么情況下使用什么算法是由客戶端決定的。
認識策略模式
策略模式的重心
策略模式的重心不是如何實現算法，而是如何組織、調用這些算法，從而讓程序結構更靈活，具有更好的維護性和擴展性。
算法的平等性
策略模式一個很大的特點就是各個策略算法的平等性。對于一系列具體的策略算法，大家的地位是完全一樣的，正因為這個平等性，才能實現算法之間可以相互替換。所有的策略算法在實現上也是相互獨立的，相互之間是沒有依賴的。
所以可以這樣描述這一系列策略算法：策略算法是相同行為的不同實現。
運行時策略的唯一性
運行期間，策略模式在每一個時刻只能使用一個具體的策略實現對象，雖然可以動態地在不同的策略實現中切換，但是同時只能使用一個。
公有的行為
經常見到的是，所有的具體策略類都有一些公有的行為。這時候，就應當把這些公有的行為放到共同的抽象策略角色Strategy類里面。當然這時候抽象策略角色必須要用Java抽象類實現，而不能使用接口。
這其實也是典型的將代碼向繼承等級結構的上方集中的標準做法。
策略模式的優點
（1）策略模式提供了管理相關的算法族的辦法。策略類的等級結構定義了一個算法或行為族。恰當使用繼承可以把公共的代碼移到父類里面，從而避免代碼重復。
（2）使用策略模式可以避免使用多重條件(if-else)語句。多重條件語句不易維護，它把采取哪一種算法或采取哪一種行為的邏輯與算法或行為的邏輯混合在一起，統統列在一個多重條件語句里面，比使用繼承的辦法還要原始和落后。
策略模式的缺點
（1）客戶端必須知道所有的策略類，并自行決定使用哪一個策略類。這就意味著客戶端必須理解這些算法的區別，以便適時選擇恰當的算法類。換言之，策略模式只適用于客戶端知道算法或行為的情況。
（2）由于策略模式把每個具體的策略實現都單獨封裝成為類，如果備選的策略很多的話，那么對象的數目就會很可觀。
（3）將簡單工廠與策略模式相結合，將客戶端創建策略轉移到工廠中，代碼如下
/**
* 這里工廠實際替換了環境角色，將策略的創建變成在工廠由類型判斷來創建對應的具體策略
*/
public class StrategyContextFactory {
private Strategy strategy;
public StrategyContextFactory(String type) {
if (type.equals("add")) {
this.strategy = new ConcreteStrategyAdd();
} else if (type.equals("sub")) {
this.strategy = new ConcreteStrategySub();
}
}
public void contextDo(){
strategy.doMath();
}
}
public class TestMain {
public static void main(String[] args) {
//客戶端需要知道具體的策略類，這意味著客戶端需要知道所有的策略方法以及他們之間的區別
// ConcreteStrategyAdd add = new ConcreteStrategyAdd();
// StrategyContext context = new StrategyContext(add);
// context.contextDo();
//簡單工廠模式和策略模式相結合，將創建具體策略的任務交給工廠，客戶端只需要知道StrategyContextFactory這個類
StrategyContextFactory f = new StrategyContextFactory("add");
f.contextDo();
}
}
