https://www.cnblogs.com/lewis0077/p/5133812.html
在講策略模式之前，我們先看一個日常生活中的小例子：
現實生活中我們到商場買東西的時候，賣場往往根據不同的客戶制定不同的報價策略，比如針對新客戶不打折扣，針對老客戶打9折，針對VIP客戶打8折...
現在我們要做一個報價管理的模塊，簡要點就是要針對不同的客戶，提供不同的折扣報價。
如果是有你來做，你會怎麼做？
我們很有可能寫出下面的代碼：
package strategy.examp02;
import java.math.BigDecimal;
public class QuoteManager {
public BigDecimal quote(BigDecimal originalPrice,String customType){
if ("新客戶".equals(customType)) {
System.out.println("抱歉！新客戶沒有折扣！");
return originalPrice;
}else if ("老客戶".equals(customType)) {
System.out.println("恭喜你！老客戶打9折！");
originalPrice = originalPrice.multiply(new BigDecimal(0.9)).setScale(2,BigDecimal.ROUND_HALF_UP);
return originalPrice;
}else if("VIP客戶".equals(customType)){
System.out.println("恭喜你！VIP客戶打8折！");
originalPrice = originalPrice.multiply(new BigDecimal(0.8)).setScale(2,BigDecimal.ROUND_HALF_UP);
return originalPrice;
}
//其他人員都是原價
return originalPrice;
}
}
經過測試，上面的代碼工作的很好，可是上面的代碼是有問題的。上面存在的問題：把不同客戶的報價的算法都放在了同一個方法裏面，使得該方法很是龐大(現在是隻是一個演示，所以看起來還不是很臃腫)。
下面看一下上面的改進，我們把不同客戶的報價的算法都單獨作爲一個方法
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4
5 public class QuoteManagerImprove {
6
7 public BigDecimal quote(BigDecimal originalPrice, String customType){
8 if ("新客戶".equals(customType)) {
9 return this.quoteNewCustomer(originalPrice);
10 }else if ("老客戶".equals(customType)) {
11 return this.quoteOldCustomer(originalPrice);
12 }else if("VIP客戶".equals(customType)){
13 return this.quoteVIPCustomer(originalPrice);
14 }
15 //其他人員都是原價
16 return originalPrice;
17 }
18
19 /**
20 * 對VIP客戶的報價算法
21 * @param originalPrice 原價
22 * @return 折後價
23 */
24 private BigDecimal quoteVIPCustomer(BigDecimal originalPrice) {
25 System.out.println("恭喜！VIP客戶打8折");
26 originalPrice = originalPrice.multiply(new BigDecimal(0.8)).setScale(2,BigDecimal.ROUND_HALF_UP);
27 return originalPrice;
28 }
29
30 /**
31 * 對老客戶的報價算法
32 * @param originalPrice 原價
33 * @return 折後價
34 */
35 private BigDecimal quoteOldCustomer(BigDecimal originalPrice) {
36 System.out.println("恭喜！老客戶打9折");
37 originalPrice = originalPrice.multiply(new BigDecimal(0.9)).setScale(2,BigDecimal.ROUND_HALF_UP);
38 return originalPrice;
39 }
40
41 /**
42 * 對新客戶的報價算法
43 * @param originalPrice 原價
44 * @return 折後價
45 */
46 private BigDecimal quoteNewCustomer(BigDecimal originalPrice) {
47 System.out.println("抱歉！新客戶沒有折扣！");
48 return originalPrice;
49 }
50
51 }
上面的代碼比剛開始的時候要好一點，它把每個具體的算法都單獨抽出來作爲一個方法，當某一個具體的算法有了變動的時候，只需要修改響應的報價算法就可以了。
但是改進後的代碼還是有問題的，那有什麼問題呢？
1.當我們新增一個客戶類型的時候，首先要添加一個該種客戶類型的報價算法方法，然後再quote方法中再加一個else if的分支，是不是感覺很是麻煩呢？而且這也違反了設計原則之一的開閉原則（open-closed-principle）.
開閉原則：
對於擴展是開放的（Open for extension）。這意味着模塊的行爲是可以擴展的。當應用的需求改變時，我們可以對模塊進行擴展，使其具有滿足那些改變的新行爲。也就是說，我們可以改變模塊的功能。
對於修改是關閉的（Closed for modification）。對模塊行爲進行擴展時，不必改動模塊的源代碼或者二進制代碼。
2.我們經常會面臨這樣的情況，不同的時期使用不同的報價規則，比如在各個節假日舉行的各種促銷活動時、商場店慶時往往都有普遍的折扣，但是促銷時間一旦過去，報價就要回到正常價格上來。按照上面的代碼我們就得修改if else裏面的代 碼很是麻煩
那有沒有什麼辦法使得我們的報價管理即可擴展、可維護，又可以方便的響應變化呢？當然有解決方案啦，就是我們下面要講的策略模式。
定義：
策略模式定義了一系列的算法，並將每一個算法封裝起來，使每個算法可以相互替代，使算法本身和使用算法的客戶端分割開來，相互獨立。
結構：
1.策略接口角色IStrategy:用來約束一系列具體的策略算法，策略上下文角色ConcreteStrategy使用此策略接口來調用具體的策略所實現的算法。
2.具體策略實現角色ConcreteStrategy:具體的策略實現，即具體的算法實現。
3.策略上下文角色StrategyContext:策略上下文，負責和具體的策略實現交互，通常策略上下文對象會持有一個真正的策略實現對象，策略上下文還可以讓具體的策略實現從其中獲取相關數據，回調策略上下文對象的方法。
UML類圖：
UML序列圖：
策略模式代碼的一般通用實現：
策略接口
1 package strategy.examp01;
2
3 //策略接口
4 public interface IStrategy {
5 //定義的抽象算法方法 來約束具體的算法實現方法
6 public void algorithmMethod();
7 }
具體的策略實現：
1 package strategy.examp01;
2
3 // 具體的策略實現
4 public class ConcreteStrategy implements IStrategy {
5 //具體的算法實現
6 @Override
7 public void algorithmMethod() {
8 System.out.println("this is ConcreteStrategy method...");
9 }
10 }
1 package strategy.examp01;
2
3 // 具體的策略實現2
4 public class ConcreteStrategy2 implements IStrategy {
5 //具體的算法實現
6 @Override
7 public void algorithmMethod() {
8 System.out.println("this is ConcreteStrategy2 method...");
9 }
10 }
策略上下文：
1 package strategy.examp01;
2
3 /**
4 * 策略上下文
5 */
6 public class StrategyContext {
7 //持有一個策略實現的引用
8 private IStrategy strategy;
9 //使用構造器注入具體的策略類
10 public StrategyContext(IStrategy strategy) {
11 this.strategy = strategy;
12 }
13
14 public void contextMethod(){
15 //調用策略實現的方法
16 strategy.algorithmMethod();
17 }
18 }
外部客戶端：
1 package strategy.examp01;
2
3 //外部客戶端
4 public class Client {
5 public static void main(String[] args) {
6 //1.創建具體測策略實現
7 IStrategy strategy = new ConcreteStrategy2();
8 //2.在創建策略上下文的同時，將具體的策略實現對象注入到策略上下文當中
9 StrategyContext ctx = new StrategyContext(strategy);
10 //3.調用上下文對象的方法來完成對具體策略實現的回調
11 ctx.contextMethod();
12 }
13 }
針對我們一開始講的報價管理的例子：我們可以應用策略模式對其進行改造，不同類型的客戶有不同的折扣，我們可以將不同類型的客戶的報價規則都封裝爲一個獨立的算法，然後抽象出這些報價算法的公共接口
公共報價策略接口：
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4 //報價策略接口
5 public interface IQuoteStrategy {
6 //獲取折後價的價格
7 BigDecimal getPrice(BigDecimal originalPrice);
8 }
新客戶報價策略實現：
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4 //新客戶的報價策略實現類
5 public class NewCustomerQuoteStrategy implements IQuoteStrategy {
6 @Override
7 public BigDecimal getPrice(BigDecimal originalPrice) {
8 System.out.println("抱歉！新客戶沒有折扣！");
9 return originalPrice;
10 }
11 }
老客戶報價策略實現：
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4 //老客戶的報價策略實現
5 public class OldCustomerQuoteStrategy implements IQuoteStrategy {
6 @Override
7 public BigDecimal getPrice(BigDecimal originalPrice) {
8 System.out.println("恭喜！老客戶享有9折優惠！");
9 originalPrice = originalPrice.multiply(new BigDecimal(0.9)).setScale(2,BigDecimal.ROUND_HALF_UP);
10 return originalPrice;
11 }
12 }
VIP客戶報價策略實現：
package strategy.examp02;
import java.math.BigDecimal;
//VIP客戶的報價策略實現
public class VIPCustomerQuoteStrategy implements IQuoteStrategy {
@Override
public BigDecimal getPrice(BigDecimal originalPrice) {
System.out.println("恭喜！VIP客戶享有8折優惠！");
originalPrice = originalPrice.multiply(new BigDecimal(0.8)).setScale(2,BigDecimal.ROUND_HALF_UP);
return originalPrice;
}
}
報價上下文：
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4 //報價上下文角色
5 public class QuoteContext {
6 //持有一個具體的報價策略
7 private IQuoteStrategy quoteStrategy;
8
9 //注入報價策略
10 public QuoteContext(IQuoteStrategy quoteStrategy){
11 this.quoteStrategy = quoteStrategy;
12 }
13
14 //回調具體報價策略的方法
15 public BigDecimal getPrice(BigDecimal originalPrice){
16 return quoteStrategy.getPrice(originalPrice);
17 }
18 }
外部客戶端：
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4 //外部客戶端
5 public class Client {
6 public static void main(String[] args) {
7 //1.創建老客戶的報價策略
8 IQuoteStrategy oldQuoteStrategy = new OldCustomerQuoteStrategy();
9
10 //2.創建報價上下文對象，並設置具體的報價策略
11 QuoteContext quoteContext = new QuoteContext(oldQuoteStrategy);
12
13 //3.調用報價上下文的方法
14 BigDecimal price = quoteContext.getPrice(new BigDecimal(100));
15
16 System.out.println("折扣價爲：" +price);
17 }
18 }
控制檯輸出：
恭喜！老客戶享有9折優惠！
折扣價爲：90.00
這個時候，商場營銷部新推出了一個客戶類型--MVP用戶（Most Valuable Person），可以享受折扣7折優惠，那該怎麼辦呢？
這個很容易，只要新增一個報價策略的實現，然後外部客戶端調用的時候，創建這個新增的報價策略實現，並設置到策略上下文就可以了，對原來已經實現的代碼沒有任何的改動。
MVP用戶的報價策略實現：
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4 //MVP客戶的報價策略實現
5 public class MVPCustomerQuoteStrategy implements IQuoteStrategy {
6 @Override
7 public BigDecimal getPrice(BigDecimal originalPrice) {
8 System.out.println("哇偶！MVP客戶享受7折優惠！！！");
9 originalPrice = originalPrice.multiply(new BigDecimal(0.7)).setScale(2,BigDecimal.ROUND_HALF_UP);
10 return originalPrice;
11 }
12 }
外部客戶端：
1 package strategy.examp02;
2
3 import java.math.BigDecimal;
4 //外部客戶端
5 public class Client {
6 public static void main(String[] args) {
7 //創建MVP客戶的報價策略
8 IQuoteStrategy mvpQuoteStrategy = new MVPCustomerQuoteStrategy();
9
10 //創建報價上下文對象，並設置具體的報價策略
11 QuoteContext quoteContext = new QuoteContext(mvpQuoteStrategy);
12
13 //調用報價上下文的方法
14 BigDecimal price = quoteContext.getPrice(new BigDecimal(100));
15
16 System.out.println("折扣價爲：" +price);
17 }
18 }
控制檯輸出：
哇偶！MVP客戶享受7折優惠！！！
折扣價爲：70.00
深入理解策略模式：
策略模式的作用：就是把具體的算法實現從業務邏輯中剝離出來，成爲一系列獨立算法類，使得它們可以相互替換。
策略模式的着重點：不是如何來實現算法，而是如何組織和調用這些算法，從而讓我們的程序結構更加的靈活、可擴展。
我們前面的第一個報價管理的示例，發現每個策略算法實現對應的都是在QuoteManager 中quote方法中的if else語句裏面，我們知道if else if語句裏面的代碼在執行的可能性方面可以說是平等的，你要麼執行if,要麼執行else,要麼執行else if。
策略模式就是把各個平等的具體實現進行抽象、封裝成爲獨立的算法類，然後通過上下文和具體的算法類來進行交互。各個策略算法都是平等的，地位是一樣的，正是由於各個算法的平等性，所以它們纔是可以相互替換的。雖然我們可以動態的切換各個策略，但是同一時刻只能使用一個策略。
在這個點上，我們舉個歷史上有名的故事作爲示例：
三國劉備取西川時，謀士龐統給的上、中、下三個計策：
上策：挑選精兵，晝夜兼行直接偷襲成都，可以一舉而定，此爲上計計也。
中策：楊懷、高沛是蜀中名將，手下有精銳部隊，而且據守關頭，我們可以裝作要回荊州，引他們輕騎來見，可就此將其擒殺，而後進兵成都，此爲中計。
下策：退還白帝，連引荊州，慢慢進圖益州，此爲下計。
這三個計策都是取西川的計策，也就是攻取西川這個問題的具體的策略算法，劉備可以採用上策，可以採用中策，當然也可以採用下策，由此可見策略模式的各種具體的策略算法都是平等的，可以相互替換。
那誰來選擇具體採用哪種計策（算法）？
在這個故事中當然是劉備選擇了，也就是外部的客戶端選擇使用某個具體的算法，然後把該算法（計策）設置到上下文當中；
還有一種情況就是客戶端不選擇具體的算法，把這個事交給上下文，這相當於劉備說我不管有哪些攻取西川的計策，我只要結果（成功的拿下西川），具體怎麼攻佔（有哪些計策，怎麼選擇）由參謀部來決定（上下文）。
下面我們演示下這種情景：
1 //攻取西川的策略
2 public interface IOccupationStrategyWestOfSiChuan {
3 public void occupationWestOfSiChuan(String msg);
4 }
1 //攻取西川的上上計策
2 public class UpperStrategy implements IOccupationStrategyWestOfSiChuan {
3 @Override
4 public void occupationWestOfSiChuan(String msg) {
5 if (msg == null || msg.length() < 5) {
6 //故意設置障礙，導致上上計策失敗
7 System.out.println("由於計劃泄露，上上計策失敗！");
8 int i = 100/0;
9 }
10 System.out.println("挑選精兵，晝夜兼行直接偷襲成都，可以一舉而定,此爲上計計也!");
11 }
12 }
1 //攻取西川的中計策
2 public class MiddleStrategy implements IOccupationStrategyWestOfSiChuan {
3 @Override
4 public void occupationWestOfSiChuan(String msg) {
5 System.out.println("楊懷、高沛是蜀中名將，手下有精銳部隊，而且據守關頭，我們可以裝作要回荊州，引他們輕騎來見，可就此將其擒殺，而後進兵成都，此爲中計。");
6 }
7 }
1 //攻取西川的下計策
2 public class LowerStrategy implements IOccupationStrategyWestOfSiChuan {
3 @Override
4 public void occupationWestOfSiChuan(String msg) {
5 System.out.println("退還白帝，連引荊州，慢慢進圖益州，此爲下計。");
6 }
7 }
1 //攻取西川參謀部，就是上下文啦，由上下文來選擇具體的策略
2 public class OccupationContext {
3
4 public void occupationWestOfSichuan(String msg){
5 //先用上上計策
6 IOccupationStrategyWestOfSiChuan strategy = new UpperStrategy();
7 try {
8 strategy.occupationWestOfSiChuan(msg);
9 } catch (Exception e) {
10 //上上計策有問題行不通之後，用中計策
11 strategy = new MiddleStrategy();
12 strategy.occupationWestOfSiChuan(msg);
13 }
14 }
15 }
1 //此時外部客戶端相當於劉備了,不管具體採用什麼計策，只要結果（成功的攻下西川）
2 public class Client {
3
4 public static void main(String[] args) {
5 OccupationContext context = new OccupationContext();
6 //這個給手下的人激勵不夠啊
7 context.occupationWestOfSichuan("拿下西川");
8 System.out.println("=========================");
9 //這個人人有賞，讓士兵有動力啊
10 context.occupationWestOfSichuan("拿下西川之後，人人有賞！");
11 }
12 }
控制檯輸出：
由於計劃泄露，上上計策失敗！
楊懷、高沛是蜀中名將，手下有精銳部隊，而且據守關頭，我們可以裝作要回荊州，引他們輕騎來見，可就此將其擒殺，而後進兵成都，此爲中計。
=========================
挑選精兵，晝夜兼行直接偷襲成都，可以一舉而定,此爲上計計也!
我們上面的策略接口採用的是接口的形式來定義的，其實這個策略接口，是廣義上的接口，不是語言層面的interface,也可以是一個抽象類，如果多個算法具有公有的數據，則可以將策略接口設計爲一個抽象類，把公共的東西放到抽象類裏面去。
策略和上下文的關係：
在策略模式中，一般情況下都是上下文持有策略的引用，以進行對具體策略的調用。但具體的策略對象也可以從上下文中獲取所需數據，可以將上下文當做參數傳入到具體策略中，具體策略通過回調上下文中的方法來獲取其所需要的數據。
下面我們演示這種情況：
在跨國公司中，一般都會在各個國家和地區設置分支機構，聘用當地人爲員工，這樣就有這樣一個需要：每月發工資的時候，中國國籍的員工要發人民幣，美國國籍的員工要發美元，英國國籍的要發英鎊。
1 //支付策略接口
2 public interface PayStrategy {
3 //在支付策略接口的支付方法中含有支付上下文作爲參數，以便在具體的支付策略中回調上下文中的方法獲取數據
4 public void pay(PayContext ctx);
5 }
1 //人民幣支付策略
2 public class RMBPay implements PayStrategy {
3 @Override
4 public void pay(PayContext ctx) {
5 System.out.println("現在給："+ctx.getUsername()+" 人民幣支付 "+ctx.getMoney()+"元！");
6 }
7 }
1 //美金支付策略
2 public class DollarPay implements PayStrategy {
3 @Override
4 public void pay(PayContext ctx) {
5 System.out.println("現在給："+ctx.getUsername()+" 美金支付 "+ctx.getMoney()+"dollar !");
6 }
7 }
1 //支付上下文,含有多個算法的公有數據
2 public class PayContext {
3 //員工姓名
4 private String username;
5 //員工的工資
6 private double money;
7 //支付策略
8 private PayStrategy payStrategy;
9
10 public void pay(){
11 //調用具體的支付策略來進行支付
12 payStrategy.pay(this);
13 }
14
15 public PayContext(String username, double money, PayStrategy payStrategy) {
16 this.username = username;
17 this.money = money;
18 this.payStrategy = payStrategy;
19 }
20
21 public String getUsername() {
22 return username;
23 }
24
25 public double getMoney() {
26 return money;
27 }
28 }
1 //外部客戶端
2 public class Client {
3 public static void main(String[] args) {
4 //創建具體的支付策略
5 PayStrategy rmbStrategy = new RMBPay();
6 PayStrategy dollarStrategy = new DollarPay();
7 //準備小王的支付上下文
8 PayContext ctx = new PayContext("小王",30000,rmbStrategy);
9 //向小王支付工資
10 ctx.pay();
11
12 //準備Jack的支付上下文
13 ctx = new PayContext("jack",10000,dollarStrategy);
14 //向Jack支付工資
15 ctx.pay();
16 }
17 }
控制檯輸出：
現在給：小王 人民幣支付 30000.0元！
現在給：jack 美金支付 10000.0dollar !
那現在我們要新增一個銀行賬戶的支付策略，該怎麼辦呢？
顯然我們應該新增一個支付找銀行賬戶的策略實現，由於需要從上下文中獲取數據，爲了不修改已有的上下文，我們可以通過繼承已有的上下文來擴展一個新的帶有銀行賬戶的上下文，然後再客戶端中使用新的策略實現和帶有銀行賬戶的上下文，這樣之前已有的實現完全不需要改動，遵守了開閉原則。
1 //銀行賬戶支付
2 public class AccountPay implements PayStrategy {
3 @Override
4 public void pay(PayContext ctx) {
5 PayContextWithAccount ctxAccount = (PayContextWithAccount) ctx;
6 System.out.println("現在給："+ctxAccount.getUsername()+"的賬戶："+ctxAccount.getAccount()+" 支付工資："+ctxAccount.getMoney()+" 元！");
7 }
8 }
1 //帶銀行賬戶的支付上下文
2 public class PayContextWithAccount extends PayContext {
3 //銀行賬戶
4 private String account;
5 public PayContextWithAccount(String username, double money, PayStrategy payStrategy,String account) {
6 super(username, money, payStrategy);
7 this.account = account;
8 }
9
10 public String getAccount() {
11 return account;
12 }
13 }
1 //外部客戶端
2 public class Client {
3 public static void main(String[] args) {
4 //創建具體的支付策略
5 PayStrategy rmbStrategy = new RMBPay();
6 PayStrategy dollarStrategy = new DollarPay();
7 //準備小王的支付上下文
8 PayContext ctx = new PayContext("小王",30000,rmbStrategy);
9 //向小王支付工資
10 ctx.pay();
11 //準備Jack的支付上下文
12 ctx = new PayContext("jack",10000,dollarStrategy);
13 //向Jack支付工資
14 ctx.pay();
15 //創建支付到銀行賬戶的支付策略
16 PayStrategy accountStrategy = new AccountPay();
17 //準備帶有銀行賬戶的上下文
18 ctx = new PayContextWithAccount("小張",40000,accountStrategy,"1234567890");
19 //向小張的賬戶支付
20 ctx.pay();
21 }
22 }
控制檯輸出：
現在給：小王 人民幣支付 30000.0元！
現在給：jack 美金支付 10000.0dollar !
現在給：小張的賬戶：1234567890 支付工資：40000.0 元！
除了上面的方法，還有其他的實現方式嗎？
當然有了，上面的實現方式是策略實現所需要的數據都是從上下文中獲取，因此擴展了上下文；現在我們可以不擴展上下文，直接從策略實現內部來獲取數據，看下面的實現：
1 //支付到銀行賬戶的策略
2 public class AccountPay2 implements PayStrategy {
3 //銀行賬戶
4 private String account;
5 public AccountPay2(String account) {
6 this.account = account;
7 }
8 @Override
9 public void pay(PayContext ctx) {
10 System.out.println("現在給："+ctx.getUsername()+"的賬戶："+getAccount()+" 支付工資："+ctx.getMoney()+" 元！");
11 }
12 public String getAccount() {
13 return account;
14 }
15 public void setAccount(String account) {
16 this.account = account;
17 }
18 }
1 //外部客戶端
2 public class Client {
3 public static void main(String[] args) {
4 //創建具體的支付策略
5 PayStrategy rmbStrategy = new RMBPay();
6 PayStrategy dollarStrategy = new DollarPay();
7 //準備小王的支付上下文
8 PayContext ctx = new PayContext("小王",30000,rmbStrategy);
9 //向小王支付工資
10 ctx.pay();
11 //準備Jack的支付上下文
12 ctx = new PayContext("jack",10000,dollarStrategy);
13 //向Jack支付工資
14 ctx.pay();
15 //創建支付到銀行賬戶的支付策略
16 PayStrategy accountStrategy = new AccountPay2("1234567890");
17 //準備上下文
18 ctx = new PayContext("小張",40000,accountStrategy);
19 //向小張的賬戶支付
20 ctx.pay();
21 }
22 }
控制檯輸出：
現在給：小王 人民幣支付 30000.0元！
現在給：jack 美金支付 10000.0dollar !
現在給：小張的賬戶：1234567890 支付工資：40000.0 元！
那我們來比較一下上面兩種實現方式：
擴展上下文的實現：
優點：具體的策略實現風格很是統一，策略實現所需要的數據都是從上下文中獲取的，在上下文中添加的數據，可以視爲公共的數據，其他的策略實現也可以使用。
缺點：很明顯如果某些數據只是特定的策略實現需要，大部分的策略實現不需要，那這些數據有“浪費”之嫌，另外如果每次添加算法數據都擴展上下文，很容易導致上下文的層級很是複雜。
在具體的策略實現上添加所需要的數據的實現：
優點：容易想到，實現簡單
缺點：與其他的策略實現風格不一致，其他的策略實現所需數據都是來自上下文，而這個策略實現一部分數據來自於自身，一部分數據來自於上下文；外部在使用這個策略實現的時候也和其他的策略實現不一致了，難以以一個統一的方式動態的切換策略實現。
策略模式在JDK中的應用：
在多線程編程中，我們經常使用線程池來管理線程，以減緩線程頻繁的創建和銷燬帶來的資源的浪費，在創建線程池的時候，經常使用一個工廠類來創建線程池Executors,實際上Executors的內部使用的是類ThreadPoolExecutor.它有一個最終的構造函數如下：
1 public ThreadPoolExecutor(int corePoolSize,
2 int maximumPoolSize,
3 long keepAliveTime,
4 TimeUnit unit,
5 BlockingQueue<Runnable> workQueue,
6 ThreadFactory threadFactory,
7 RejectedExecutionHandler handler) {
8 if (corePoolSize < 0 ||
9 maximumPoolSize <= 0 ||
10 maximumPoolSize < corePoolSize ||
11 keepAliveTime < 0)
12 throw new IllegalArgumentException();
13 if (workQueue == null || threadFactory == null || handler == null)
14 throw new NullPointerException();
15 this.corePoolSize = corePoolSize;
16 this.maximumPoolSize = maximumPoolSize;
17 this.workQueue = workQueue;
18 this.keepAliveTime = unit.toNanos(keepAliveTime);
19 this.threadFactory = threadFactory;
20 this.handler = handler;
21 }
corePoolSize：線程池中的核心線程數量，即使這些線程沒有任務幹，也不會將其銷燬。
maximumPoolSize：線程池中的最多能夠創建的線程數量。
keepAliveTime：當線程池中的線程數量大於corePoolSize時，多餘的線程等待新任務的最長時間。
unit：keepAliveTime的時間單位。
workQueue：在線程池中的線程還沒有還得及執行任務之前，保存任務的隊列（當線程池中的線程都有任務在執行的時候，仍然有任務不斷的提交過來，這些任務保存在workQueue隊列中）。
threadFactory：創建線程池中線程的工廠。
handler：當線程池中沒有多餘的線程來執行任務，並且保存任務的多列也滿了（指的是有界隊列），對仍在提交給線程池的任務的處理策略。
RejectedExecutionHandler 是一個策略接口，用在當線程池中沒有多餘的線程來執行任務，並且保存任務的多列也滿了（指的是有界隊列），對仍在提交給線程池的任務的處理策略。
public interface RejectedExecutionHandler {
/**
*當ThreadPoolExecutor的execut方法調用時，並且ThreadPoolExecutor不能接受一個任務Task時，該方法就有可能被調用。
* 不能接受一個任務Task的原因：有可能是沒有多餘的線程來處理，有可能是workqueue隊列中沒有多餘的位置來存放該任務，該方法有可能拋出一個未受檢的異常RejectedExecutionException
* @param r the runnable task requested to be executed
* @param executor the executor attempting to execute this task
* @throws RejectedExecutionException if there is no remedy
*/
void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}
該策略接口有四個實現類：
AbortPolicy:該策略是直接將提交的任務拋棄掉，並拋出RejectedExecutionException異常。
/**
* A handler for rejected tasks that throws a
* <tt>RejectedExecutionException</tt>.
*/
public static class AbortPolicy implements RejectedExecutionHandler {
/**
* Creates an <tt>AbortPolicy</tt>.
*/
public AbortPolicy() { }
/**
* Always throws RejectedExecutionException.
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
* @throws RejectedExecutionException always.
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
throw new RejectedExecutionException();
}
}
DiscardPolicy:該策略也是將任務拋棄掉（對於提交的任務不管不問，什麼也不做），不過並不拋出異常。
/**
* A handler for rejected tasks that silently discards the
* rejected task.
*/
public static class DiscardPolicy implements RejectedExecutionHandler {
/**
* Creates a <tt>DiscardPolicy</tt>.
*/
public DiscardPolicy() { }
/**
* Does nothing, which has the effect of discarding task r.
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
}
}
DiscardOldestPolicy:該策略是當執行器未關閉時，從任務隊列workQueue中取出第一個任務，並拋棄這第一個任務，進而有空間存儲剛剛提交的任務。使用該策略要特別小心，因爲它會直接拋棄之前的任務。
/**
* A handler for rejected tasks that discards the oldest unhandled
* request and then retries <tt>execute</tt>, unless the executor
* is shut down, in which case the task is discarded.
*/
public static class DiscardOldestPolicy implements RejectedExecutionHandler {
/**
* Creates a <tt>DiscardOldestPolicy</tt> for the given executor.
*/
public DiscardOldestPolicy() { }
/**
* Obtains and ignores the next task that the executor
* would otherwise execute, if one is immediately available,
* and then retries execution of task r, unless the executor
* is shut down, in which case task r is instead discarded.
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
e.getQueue().poll();
e.execute(r);
}
}
}
CallerRunsPolicy:該策略並沒有拋棄任何的任務，由於線程池中已經沒有了多餘的線程來分配該任務，該策略是在當前線程（調用者線程）中直接執行該任務。
/**
* A handler for rejected tasks that runs the rejected task
* directly in the calling thread of the {@code execute} method,
* unless the executor has been shut down, in which case the task
* is discarded.
*/
public static class CallerRunsPolicy implements RejectedExecutionHandler {
/**
* Creates a {@code CallerRunsPolicy}.
*/
public CallerRunsPolicy() { }
/**
* Executes task r in the caller's thread, unless the executor
* has been shut down, in which case the task is discarded.
*
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
r.run();
}
}
}
類ThreadPoolExecutor中持有一個RejectedExecutionHandler接口的引用，以便在構造函數中可以由外部客戶端自己制定具體的策略並注入。下面看一下其類圖：
策略模式的優點：
1.策略模式的功能就是通過抽象、封裝來定義一系列的算法，使得這些算法可以相互替換，所以爲這些算法定義一個公共的接口，以約束這些算法的功能實現。如果這些算法具有公共的功能，可以將接口變爲抽象類，將公共功能放到抽象父類裏面。
2.策略模式的一系列算法是可以相互替換的、是平等的，寫在一起就是if-else組織結構，如果算法實現裏又有條件語句，就構成了多重條件語句，可以用策略模式，避免這樣的多重條件語句。
3.擴展性更好：在策略模式中擴展策略實現非常的容易，只要新增一個策略實現類，然後在使用策略實現的地方，使用這個新的策略實現就好了。
策略模式的缺點：
1.客戶端必須瞭解所有的策略，清楚它們的不同：
如果由客戶端來決定使用何種算法，那客戶端必須知道所有的策略，清楚各個策略的功能和不同，這樣才能做出正確的選擇，但是這暴露了策略的具體實現。
2.增加了對象的數量：
由於策略模式將每個具體的算法都單獨封裝爲一個策略類，如果可選的策略有很多的話，那對象的數量也會很多。
3.只適合偏平的算法結構：
由於策略模式的各個策略實現是平等的關係（可相互替換），實際上就構成了一個扁平的算法結構。即一個策略接口下面有多個平等的策略實現（多個策略實現是兄弟關係），並且運行時只能有一個算法被使用。這就限制了算法的使用層級，且不能被嵌套。
策略模式的本質：
分離算法，選擇實現。
如果你仔細思考策略模式的結構和功能的話，就會發現：如果沒有上下文，策略模式就回到了最基本的接口和實現了，只要是面向接口編程，就能夠享受到面向接口編程帶來的好處，通過一個統一的策略接口來封裝和分離各個具體的策略實現，無需關係具體的策略實現。
貌似沒有上下文什麼事，但是如果沒有上下文的話，客戶端就必須直接和具體的策略實現進行交互了，尤其是需要提供一些公共功能或者是存儲一些狀態的時候，會大大增加客戶端使用的難度；引入上下文之後，這部分工作可以由上下文來完成，客戶端只需要和上下文進行交互就可以了。這樣可以讓策略模式更具有整體性，客戶端也更加的簡單。
策略模式體現了開閉原則：策略模式把一系列的可變算法進行封裝，從而定義了良好的程序結構，在出現新的算法的時候，可以很容易的將新的算法實現加入到已有的系統中，而已有的實現不需要修改。
策略模式體現了里氏替換原則：策略模式是一個扁平的結構，各個策略實現都是兄弟關係，實現了同一個接口或者繼承了同一個抽象類。這樣只要使用策略的客戶端保持面向抽象編程，就可以動態的切換不同的策略實現以進行替換。