[[404639]]

最近有一個學妹在跟我溝通如何有效的去避免代碼中一長串的if else判斷或者switch條件判斷?針對更多的回答就是合理的去使用設計來規避這個問題。

在設計模式中，可以使用工廠模式或者策略模式來處理這類問題，之前已經分享了工廠模式，感興趣的同學可以去復習一下。

設計模式系列往期文章：

• 單例模式
• 工廠模式
• 流程引擎
• 建造者模式
• 原型模式
• 責任鏈模式
• 觀察者模式

那么工廠模式和策略模式有什么區別呢?

• 工廠模式是屬于創建型設計模式，主要用來針對不同類型創建不同的對象，達到解偶類對象。
• 策略模式是屬于行為型設計模式，主要是針對不同的策略做出對應行為，達到行為解偶

本次就來具體聊聊策略模式它是如何做到行為解耦

大綱

定義

什么是策略模式?它的原理實現是怎么樣的?

定義一系列算法，封裝每個算法，并使他們可以互換，不同的策略可以讓算法獨立于使用它們的客戶而變化。以上定義來自設計模式之美

感覺有點抽象?那就來看一張結構圖吧

• Strategy(抽象策略)：抽象策略類，并且定義策略執行入口
• ConcreteStrategy(具體策略)：實現抽象策略，實現algorithm方法
• Context(環境)：運行特定的策略類。

這么看結構其實還是不復雜的，而且跟狀態模式類似。

那么這個代碼怎么實現?

舉個例子，汽車大家肯定都不陌生，愿大家早日完成汽車夢，汽車的不同檔(concreteStrategy)就好比不同的策略，駕駛者選擇幾檔則汽車按幾檔的速度前進，整個選擇權在駕駛者(context)手中。

public interface GearStrategy { 
 
    // 定義策略執行方法 
    void algorithm(String param); 
} 

首先還是先定義抽象策略

這里是用接口的形式，還有一種方式可以用抽象方法abstract來寫也是一樣的。具體就看大家自己選擇了。

public abstract class GearStrategyAbstract { 
 // 定義策略執行方法 
 abstract void algorithm(String param); 
} 

public class GearStrategyOne implements GearStrategy { 
 
    @Override 
    public void algorithm(String param) { 
        System.out.println("當前檔位" + param); 
    } 
} 

其次定義具體檔位策略，實現algorithm方法。

public class Context { 
  // 緩存所有的策略，當前是無狀態的，可以共享策略類對象 
    private static final Map<String, GearStrategy> strategies = new HashMap<>(); 
 
    // 第一種寫法 
    static { 
        strategies.put("one", new GearStrategyOne()); 
    } 
 
    public static GearStrategy getStrategy(String type) { 
        if (type == null || type.isEmpty()) { 
            throw new IllegalArgumentException("type should not be empty."); 
        } 
        return strategies.get(type); 
    } 
 
    // 第二種寫法 
    public static GearStrategy getStrategySecond(String type) { 
        if (type == null || type.isEmpty()) { 
            throw new IllegalArgumentException("type should not be empty."); 
        } 
        if (type.equals("one")) { 
            return new GearStrategyOne(); 
        } 
        return null; 
    } 
 
 
    public static void main(String[] args) { 
        // 測試結果 
        GearStrategy strategyOne = Context.getStrategy("one"); 
        strategyOne.algorithm("1檔"); 
         // 結果：當前檔位1檔 
        GearStrategy strategyTwo = Context.getStrategySecond("one"); 
        strategyTwo.algorithm("1檔"); 
        // 結果：當前檔位1檔 
    } 
 
} 

最后就是實現運行時環境(Context)，你可以定義成StrategyFactory，但都是一個意思。

在main方法里面的測試demo，可以看到通過不同的type類型，可以實現不同的策略，這就是策略模式主要思想。

在Context里面定義了兩種寫法：

• 第一種是維護了一個strategies的Map容器。用這種方式就需要判斷每種策略是否可以共享使用，它只是作為算法的實現。
• 第二種是直接通過有狀態的類，每次根據類型new一個新的策略類對象。這個就需要根據實際業務場景去做的判斷。

框架的應用

策略模式在框架中也在一個很常見的地方體現出來了，而且大家肯定都有使用過。

那就是JDK中的線程池ThreadPoolExecutor

首先都是類似于這樣定義一個線程池，里面實現線程池的異常策略。

這個線程池的異常策略就是用的策略模式的思想。

在源碼中有RejectedExecutionHandler這個抽象異常策略接口，同時它也有四種拒絕策略。關系圖如下：

這就是在框架中的體現了，根據自己的業務場景，合理的選擇線程池的異常策略。

業務改造舉例

在真實的業務場景中策略模式也還是應用很多的。

在社交電商中分享商品是一個很重要的環節，假設現在要我們實現一個分享圖片功能，比如當前有 單商品、多商品、下單、會場、邀請、小程序鏈接等等多種分享場景。

針對上線這個流程圖先用if else語句做一個普通業務代碼判斷，就像下面的這中方式：

public class SingleItemShare { 
    // 單商品 
    public void algorithm(String param) { 
        System.out.println("當前分享圖片是" + param); 
    } 
} 
public class MultiItemShare { 
    // 多商品 
    public void algorithm(String param) { 
        System.out.println("當前分享圖片是" + param); 
    } 
} 
public class OrderItemShare { 
    // 下單 
    public void algorithm(String param) { 
        System.out.println("當前分享圖片是" + param); 
    } 
} 
public class ShareFactory { 
 
    public static void main(String[] args) throws Exception { 
        Integer shareType = 1; 
       // 測試業務邏輯 
        if (shareType.equals(ShareType.SINGLE.getCode())) { 
            SingleItemShare singleItemShare = new SingleItemShare(); 
            singleItemShare.algorithm("單商品"); 
        } else if (shareType.equals(ShareType.MULTI.getCode())) { 
            MultiItemShare multiItemShare = new MultiItemShare(); 
            multiItemShare.algorithm("多商品"); 
        } else if (shareType.equals(ShareType.ORDER.getCode())) { 
            OrderItemShare orderItemShare = new OrderItemShare(); 
            orderItemShare.algorithm("下單"); 
        } else { 
            throw new Exception("未知分享類型"); 
        } 
        // .....省略更多分享場景 
    } 
 
    enum ShareType { 
        SINGLE(1, "單商品"), 
        MULTI(2, "多商品"), 
        ORDER(3, "下單"); 
        /** 
         * 場景對應的編碼 
         */ 
        private Integer code; 
        /** 
         * 業務場景描述 
         */ 
        private String desc; 
        ShareType(Integer code, String desc) { 
            this.code = code; 
            this.desc = desc; 
        } 
        public Integer getCode() { 
            return code; 
        } 
       // 省略 get set 方法 
    } 
} 

這里大家可以看到每新加一種分享類型，就需要加一次if else 判斷，當如果有十幾種場景的時候那代碼整體就會非常的長，看起來給人的感覺也不是很舒服。

接下來就看看如何用策略模式進行重構：

public interface ShareStrategy { 
    // 定義分享策略執行方法 
    void shareAlgorithm(String param); 
} 
 
public class OrderItemShare implements ShareStrategy { 
    @Override 
    public void shareAlgorithm(String param) { 
        System.out.println("當前分享圖片是" + param); 
    } 
} 
 
// 省略 MultiItemShare以及SingleItemShare策略 
 
// 分享工廠 
public class ShareFactory { 
  // 定義策略枚舉 
    enum ShareType { 
        SINGLE("single", "單商品"), 
        MULTI("multi", "多商品"), 
        ORDER("order", "下單"); 
        // 場景對應的編碼 
        private String code; 
        
        // 業務場景描述 
        private String desc; 
        ShareType(String code, String desc) { 
            this.code = code; 
            this.desc = desc; 
        } 
        public String getCode() { 
            return code; 
        } 
       // 省略 get set 方法 
    } 
  // 定義策略map緩存 
    private static final Map<String, ShareStrategy> shareStrategies = new       HashMap<>(); 
    static { 
        shareStrategies.put("order", new OrderItemShare()); 
        shareStrategies.put("single", new SingleItemShare()); 
        shareStrategies.put("multi", new MultiItemShare()); 
    } 
    // 獲取指定策略 
    public static ShareStrategy getShareStrategy(String type) { 
        if (type == null || type.isEmpty()) { 
            throw new IllegalArgumentException("type should not be empty."); 
        } 
        return shareStrategies.get(type); 
    } 
  
    public static void main(String[] args) { 
        // 測試demo 
        String shareType = "order"; 
        ShareStrategy shareStrategy = ShareFactory.getShareStrategy(shareType); 
        shareStrategy.shareAlgorithm("order"); 
        // 輸出結果：當前分享圖片是order 
    } 
} 

這里策略模式就已經改造完了。在client請求端，根本看不到那么多的if else判斷，只需要傳入對應的策略方式即可，這里我們維護了一個策略緩存map，在直接調用的ShareFactory獲取策略的時候就直接是從換種獲取策略類對象。

這就已經達到了行為解偶的思想。同時也避免了長串的if else 判斷。

優點：

• 算法策略可以自由實現切換
• 擴展性好，加一個策略，只需要增加一個類

缺點：

• 策略類數量多
• 需要維護一個策略枚舉，讓別人知道你當前具有哪些策略

總結

以上就講完了策略模式，整體看上去其實還是比較簡單的，還是那句話學習設計模式我們還是要學習每種設計模式的思想，任何一種設計模式存在即合理。當然也不要因為設計模式而設計代碼，那樣反而得不償失。