前言

在軟件開發中，設計模式是為了解決常見問題而提供的一套可重用的解決方案。策略模式（Strategy Pattern）是其中一種常見的設計模式，它屬于行為型模式。該模式的核心思想是將不同的算法封裝成獨立的策略類，使得它們可以相互替換，而不影響客戶端的使用。

策略模式與其他設計模式有一些明顯的區別。與模板方法模式相比，策略模式強調算法的靈活性，允許在運行時切換不同的策略。與狀態模式相比，策略模式更注重不同算法之間的替換性，而非狀態的內部轉換。

優缺點

優點
策略類之間相互獨立，易于擴展和維護。

可以在運行時動態切換策略，靈活性高。

提供了一種可替代繼承的方案，避免繼承層次的臃腫。

缺點
客戶端需要了解不同的策略類，增加了使用的復雜度。

策略模式增加了類的數量，可能會導致系統更加龐大。

使用場景

如果在一個系統里面有許多類，它們之間的區別僅在于它們的行為，那么使用策略模式可以動態地讓一個對象在許多行為中選擇一種行為
一個系統需要動態地在幾種算法中選擇一種
如果一個對象有很多的行為，如果不用恰當的模式，這些行為就只好使用多重的條件選擇語句來實現
如果一個系統的策略多于四個，就需要考慮使用混合模式，解決策略類膨脹的問題

角色定義

• 策略Context(上下文)

策略模式定義上下文角色本意是為了通過不同策略對象讓上下文調用對應的算法或行為。

• 策略抽象

策略抽象主要設定行為，定義策略需要具有哪些行為。

• 策略實現

具體策略的實現，實現策略抽象行為具體細節。

UML

• FruitMarket(策略抽象)
• PapayaPeddler、KiwifruitPeddler、WatermelonPeddler(策略算法實現)
• SellFruitsContext(策略Context)

模擬示例

//賣水果策略 上下文
public class SellFruitsContext{//水果市場策略抽象private FruitMarket fruitMarket;public SellFruitsContext() {}public SellFruitsContext(FruitMarket fruitMarket) {this.fruitMarket = fruitMarket;}//調用策略方法public void sellFruit(){this.fruitMarket.sellFruits();}
}

//水果市場 策略抽象
public interface FruitMarket {void sellFruits();
}

//策略實現者
public class KiwifruitPeddler implements FruitMarket {public void sellFruits() {System.out.println("賣獼猴桃咯，保熟！！");}
}public class PapayaPeddler  implements FruitMarket {public void sellFruits() {System.out.println("賣木瓜咯，瓜保熟！！");}
}public class WatermelonPeddler implements FruitMarket {public void sellFruits() {System.out.println("賣西瓜咯，瓜保熟！！");}
}

//定義類型枚舉 通過 類型獲取 對應的策略算法
public enum FruitEnum {KIWIFRUIT(1,KiwifruitPeddler.class),PAPAYA(2,PapayaPeddler.class),WATERMELON(3,WatermelonPeddler.class);//水果類型private Integer fruitType;//水果類型對應的策略算法private Class c;FruitEnum() {}FruitEnum(Integer fruitType, Class c) {this.fruitType = fruitType;this.c = c;}public FruitEnum getFruitEnumByType(Integer fruitType){for (FruitEnum value : FruitEnum.values()) {if(value.fruitType==fruitType)return value;}return null;}
}

小結

通過類型在枚舉類獲取對應策略算法實現類，將策略算法實現類傳入策略上下文，通過策略上下文調用具體的策略算法。后期業務擴展可新增枚舉數據添加策略算法實現類，完成對擴展業務的實現。

策略模式在代碼重構的時候是很常見的，減少大量if else代碼、增強代碼擴展性、策略算法的靈活切換、避免單個條件重復判斷，很多情況選擇switch以及if else會比較多，但是隨著業務復雜度業務代碼量上來了，隨之代碼的擴展性以及可讀性降低代碼也顯得極其臃腫，雖說對于每一種算法都要為其建立一種策略類，相對比較懶的程序員更愿意寫if else，有時候也不要覺得策略算法實現類太多，因為策略算法的多少取決于你的業務復雜度，正是因為策略算法很多才體現出業務的復雜,才更需要用好策略模式。