策略模式核心價值在于對“行為”的抽象和封裝，通過定義一系列可相互替換的算法，使其獨立于使用它的客戶端而變化。1.策略接口定義算法抽象；2.具體策略類實現(xiàn)不同算法；3.上下文持有策略引用并委托執(zhí)行。它避免了復雜的if-else邏輯，提高系統(tǒng)靈活性和可維護性，適用于多變的業(yè)務規(guī)則如折扣計算、數(shù)據(jù)解析等場景。
策略模式在Java設計中，我認為它最核心的價值在于其對“行為”的抽象和封裝。簡單來說，當你面對一個任務，但完成這個任務的方式卻有很多種，而且這些方式可能還會不斷增加時，策略模式就能幫你把這些不同的“方式”獨立出來，讓它們可以互相替換，而不會影響到使用它們的“上下文”。這就像你有一個工具箱，里面放著各種功能的螺絲刀，你需要擰不同類型的螺絲時，只需要從工具箱里拿對的那把，而不是每次都去改造你的電動螺絲刀本體。
解決方案
策略模式的核心思想是定義一系列的算法，將每一個算法封裝起來，并使它們可以相互替換。它讓算法獨立于使用它的客戶端而變化。通常，我們會看到三個主要角色：
- 策略接口 (Strategy Interface)：這是一個普通的java接口，它定義了所有具體策略類必須實現(xiàn)的方法。這個方法就是策略模式中“算法”的抽象。
- 具體策略類 (Concrete Strategies)：這些類實現(xiàn)了策略接口，每一個具體策略類都代表了一種特定的算法實現(xiàn)。比如，如果你在處理支付，那么微信支付、支付寶支付、銀行卡支付都可以是不同的具體策略。
- 上下文 (Context)：上下文類持有一個對策略接口的引用。它不直接實現(xiàn)任何具體的算法，而是將請求委托給它當前持有的策略對象。客戶端與上下文交互，上下文再根據(jù)需要或配置來使用不同的策略。
通過這種方式，客戶端代碼無需知道具體算法的實現(xiàn)細節(jié)，只需要知道如何與上下文交互即可。當需要切換算法時，只需要在運行時為上下文設置不同的具體策略對象，而無需修改上下文的代碼，這極大地提高了系統(tǒng)的靈活性和可維護性。在我看來，這正是面向?qū)ο?/b>設計中“開閉原則”的絕佳體現(xiàn)——對擴展開放，對修改關閉。
立即學習“Java免費學習筆記（深入）”；
如何在復雜的業(yè)務規(guī)則中應用策略模式？
在實際開發(fā)中，我們經(jīng)常會遇到業(yè)務規(guī)則復雜多變的情況，比如各種優(yōu)惠券的計算、積分兌換規(guī)則、不同用戶等級的權(quán)限判斷等等。這些場景往往伴隨著大量的if-else if或switch-case語句，導致代碼臃腫、難以維護。策略模式在這里就能大顯身手。
以一個電商平臺的訂單折扣計算為例。一個訂單可能會有多種折扣規(guī)則：新人首單優(yōu)惠、滿減活動、會員等級折扣、優(yōu)惠券抵扣等等。如果把所有這些計算邏輯都堆在一個calculateOrderPrice方法里，那簡直就是一場噩夢。
我們可以定義一個DiscountStrategy接口，里面有一個applyDiscount(Order order)方法。然后為每一種折扣規(guī)則實現(xiàn)一個具體的策略類，比如NewUserDiscountStrategy、FullreductionStrategy、MemberLevelDiscountStrategy。在訂單服務中，我們可以維護一個策略的集合，或者根據(jù)訂單的屬性（比如是否是新用戶、是否有優(yōu)惠券）動態(tài)地選擇并應用一個或多個折扣策略。
// 策略接口 public interface DiscountStrategy { BigDecimal applyDiscount(Order order); } // 具體策略1：新人折扣 public class NewUserDiscountStrategy implements DiscountStrategy { @Override public BigDecimal applyDiscount(Order order) { // 假設只有新用戶才享受此折扣 if (order.isNewUser()) { return order.getTotalAmount().multiply(new BigDecimal("0.9")); // 9折 } return order.getTotalAmount(); } } // 具體策略2：滿減折扣 public class FullReductionStrategy implements DiscountStrategy { private BigDecimal threshold; private BigDecimal reductionAmount; public FullReductionStrategy(BigDecimal threshold, BigDecimal reductionAmount) { this.threshold = threshold; this.reductionAmount = reductionAmount; } @Override public BigDecimal applyDiscount(Order order) { if (order.getTotalAmount().compareTo(threshold) >= 0) { return order.getTotalAmount().subtract(reductionAmount); } return order.getTotalAmount(); } } // 上下文：訂單服務 public class OrderService { private List<DiscountStrategy> strategies; public OrderService(List<DiscountStrategy> strategies) { this.strategies = strategies; } public BigDecimal calculateFinalPrice(Order order) { BigDecimal finalPrice = order.getTotalAmount(); for (DiscountStrategy strategy : strategies) { // 這里可以設計成鏈式調(diào)用，或者疊加折扣 finalPrice = strategy.applyDiscount(order); // 簡化處理，假設是順序應用 } return finalPrice; } }
通過這種方式，每當新增一種折扣規(guī)則時，我只需要添加一個新的具體策略類，而無需修改OrderService的calculateFinalPrice方法，這讓代碼變得非常干凈和可擴展。
為什么說策略模式是避免“If-Else地獄”的利器？
“If-Else地獄”是很多開發(fā)者都深惡痛絕的現(xiàn)象。當一個方法內(nèi)部充斥著大量的條件判斷，根據(jù)不同的條件執(zhí)行不同的邏輯時，代碼的可讀性、可維護性和可擴展性都會變得非常糟糕。每次需求變更或新增一種情況，你都得小心翼翼地修改這個巨大的if-else塊，生怕引入新的bug。
策略模式正是解決這個問題的有效手段。它將條件判斷的“結(jié)果”——也就是不同的業(yè)務邏輯——抽離出來，封裝到獨立的策略類中。原本在if-else中判斷的條件，現(xiàn)在變成了選擇哪個具體策略的依據(jù)。
舉個例子，假設你有一個數(shù)據(jù)處理服務，需要根據(jù)不同的數(shù)據(jù)類型（xml、json、CSV）進行不同的解析。
沒有策略模式，你可能會寫：
public void processData(String dataType, String data) { if ("XML".equals(dataType)) { // 解析XML邏輯 } else if ("JSON".equals(dataType)) { // 解析JSON邏輯 } else if ("CSV".equals(dataType)) { // 解析CSV邏輯 } else { throw new IllegalArgumentException("Unsupported data type"); } }
這看起來還行，但如果未來要支持更多數(shù)據(jù)類型，這個方法會變得越來越長。
使用策略模式，你可以這樣設計：
// 策略接口 public interface DataParser { void parse(String data); } // 具體策略：XML解析器 public class XmlDataParser implements DataParser { @Override public void parse(String data) { System.out.println("Parsing XML data..."); // 實際XML解析邏輯 } } // 具體策略：JSON解析器 public class JsonDataParser implements DataParser { @Override public void parse(String data) { System.out.println("Parsing JSON data..."); // 實際JSON解析邏輯 } } // 上下文：數(shù)據(jù)處理服務 public class DataProcessingService { private Map<String, DataParser> parserMap; public DataProcessingService() { parserMap = new HashMap<>(); parserMap.put("XML", new XmlDataParser()); parserMap.put("JSON", new JsonDataParser()); // 可以通過工廠模式或Spring IoC來管理這些策略實例 } public void process(String dataType, String data) { DataParser parser = parserMap.get(dataType); if (parser == null) { throw new IllegalArgumentException("Unsupported data type: " + dataType); } parser.parse(data); } }
現(xiàn)在，每當需要支持新的數(shù)據(jù)類型時，你只需要創(chuàng)建一個新的DataParser實現(xiàn)類，并在DataProcessingService的parserMap中注冊它，process方法本身是完全不需要改動的。這不僅消除了if-else，還使得每個解析邏輯都獨立封裝，更易于測試和理解。這種解耦帶來的好處是顯而易見的，它讓系統(tǒng)更加健壯和靈活。
策略模式在算法族管理上的優(yōu)勢體現(xiàn)在哪里？
策略模式在管理“算法族”方面有著天然的優(yōu)勢。所謂“算法族”，指的是一組完成相同目標，但內(nèi)部實現(xiàn)方式各異的算法。比如，排序算法（冒泡、快排、歸并）、圖像處理算法（模糊、銳化、灰度化）、路由算法（最短路徑、負載均衡）等等。
策略模式允許你將這些相關的算法封裝在一個共同的接口之下，使得它們可以互換使用。這種優(yōu)勢主要體現(xiàn)在以下幾個方面：
- 易于擴展和維護：當出現(xiàn)新的算法需求時，你只需要實現(xiàn)新的具體策略類，而無需修改現(xiàn)有的任何代碼。這符合“開閉原則”，極大地降低了維護成本和引入新bug的風險。比如，你的系統(tǒng)現(xiàn)在支持冒泡排序，未來想引入快速排序，只需添加一個QuickSortStrategy，而不用改動調(diào)用排序的地方。
- 運行時算法切換：策略模式使得在運行時動態(tài)選擇或切換算法成為可能。例如，一個報告生成器可能需要根據(jù)用戶選擇的格式（PDF、excel、html）來導出數(shù)據(jù)。每種導出格式都是一個具體策略，報告生成器根據(jù)用戶選擇動態(tài)加載相應的策略。
- 避免代碼重復和臃腫：如果沒有策略模式，你可能會在一個方法中包含所有算法的實現(xiàn)，并通過條件語句來選擇執(zhí)行哪一個。這會導致方法體龐大，邏輯復雜，難以閱讀和測試。策略模式將每個算法封裝在獨立的類中，使得代碼結(jié)構(gòu)清晰，每個類只負責單一的職責。
- 提高代碼的復用性：一旦一個算法被封裝成一個策略，它就可以在任何需要它的上下文中使用，而不僅僅局限于最初設計的那個場景。這促進了代碼的模塊化和復用。
在我看來，策略模式并非僅僅是“消除if-else”的銀彈，它更深層次的意義在于提供了一種清晰、優(yōu)雅的方式來組織和管理那些行為上一致但實現(xiàn)上各異的業(yè)務邏輯。它強制你思考和抽象你的“行為”，從而構(gòu)建出更加靈活、可適應變化的系統(tǒng)架構(gòu)。當然，任何模式都有其適用場景，如果你的“算法”只有一個，或者極少變化，那么引入策略模式可能會顯得過度設計。但對于那些“多變的行為”，它絕對是值得你認真考慮的設計利器。
