策略模式核心价值在于对“行为”的抽象和封装，通过定义一系列可相互替换的算法，使其独立于使用它的客户端而变化。1.策略接口定义算法抽象；2.具体策略类实现不同算法；3.上下文持有策略引用并委托执行。它避免了复杂的if-else逻辑，提高系统灵活性和可维护性，适用于多变的业务规则如折扣计算、数据解析等场景。
策略模式在Java设计中，我认为它最核心的价值在于其对“行为”的抽象和封装。简单来说，当你面对一个任务，但完成这个任务的方式却有很多种，而且这些方式可能还会不断增加时，策略模式就能帮你把这些不同的“方式”独立出来，让它们可以互相替换，而不会影响到使用它们的“上下文”。这就像你有一个工具箱，里面放着各种功能的螺丝刀，你需要拧不同类型的螺丝时，只需要从工具箱里拿对的那把，而不是每次都去改造你的电动螺丝刀本体。
解决方案
策略模式的核心思想是定义一系列的算法，将每一个算法封装起来，并使它们可以相互替换。它让算法独立于使用它的客户端而变化。通常，我们会看到三个主要角色：
- 策略接口 (Strategy Interface)：这是一个普通的java接口，它定义了所有具体策略类必须实现的方法。这个方法就是策略模式中“算法”的抽象。
- 具体策略类 (Concrete Strategies)：这些类实现了策略接口，每一个具体策略类都代表了一种特定的算法实现。比如，如果你在处理支付，那么微信支付、支付宝支付、银行卡支付都可以是不同的具体策略。
- 上下文 (Context)：上下文类持有一个对策略接口的引用。它不直接实现任何具体的算法，而是将请求委托给它当前持有的策略对象。客户端与上下文交互，上下文再根据需要或配置来使用不同的策略。
通过这种方式，客户端代码无需知道具体算法的实现细节，只需要知道如何与上下文交互即可。当需要切换算法时，只需要在运行时为上下文设置不同的具体策略对象，而无需修改上下文的代码，这极大地提高了系统的灵活性和可维护性。在我看来，这正是面向对象设计中“开闭原则”的绝佳体现——对扩展开放，对修改关闭。
立即学习“Java免费学习笔记（深入）”；
如何在复杂的业务规则中应用策略模式？
在实际开发中，我们经常会遇到业务规则复杂多变的情况，比如各种优惠券的计算、积分兑换规则、不同用户等级的权限判断等等。这些场景往往伴随着大量的if-else if或switch-case语句，导致代码臃肿、难以维护。策略模式在这里就能大显身手。
以一个电商平台的订单折扣计算为例。一个订单可能会有多种折扣规则：新人首单优惠、满减活动、会员等级折扣、优惠券抵扣等等。如果把所有这些计算逻辑都堆在一个calculateOrderPrice方法里，那简直就是一场噩梦。
我们可以定义一个DiscountStrategy接口，里面有一个applyDiscount(Order order)方法。然后为每一种折扣规则实现一个具体的策略类，比如NewUserDiscountStrategy、FullreductionStrategy、MemberLevelDiscountStrategy。在订单服务中，我们可以维护一个策略的集合，或者根据订单的属性（比如是否是新用户、是否有优惠券）动态地选择并应用一个或多个折扣策略。
// 策略接口 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) { // 这里可以设计成链式调用，或者叠加折扣 finalPrice = strategy.applyDiscount(order); // 简化处理，假设是顺序应用 } return finalPrice; } }
通过这种方式，每当新增一种折扣规则时，我只需要添加一个新的具体策略类，而无需修改OrderService的calculateFinalPrice方法，这让代码变得非常干净和可扩展。
为什么说策略模式是避免“If-Else地狱”的利器？
“If-Else地狱”是很多开发者都深恶痛绝的现象。当一个方法内部充斥着大量的条件判断，根据不同的条件执行不同的逻辑时，代码的可读性、可维护性和可扩展性都会变得非常糟糕。每次需求变更或新增一种情况，你都得小心翼翼地修改这个巨大的if-else块，生怕引入新的bug。
策略模式正是解决这个问题的有效手段。它将条件判断的“结果”——也就是不同的业务逻辑——抽离出来，封装到独立的策略类中。原本在if-else中判断的条件，现在变成了选择哪个具体策略的依据。
举个例子，假设你有一个数据处理服务，需要根据不同的数据类型（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"); } }
这看起来还行，但如果未来要支持更多数据类型，这个方法会变得越来越长。
使用策略模式，你可以这样设计：
// 策略接口 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解析逻辑 } } // 上下文：数据处理服务 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); } }
现在，每当需要支持新的数据类型时，你只需要创建一个新的DataParser实现类，并在DataProcessingService的parserMap中注册它，process方法本身是完全不需要改动的。这不仅消除了if-else，还使得每个解析逻辑都独立封装，更易于测试和理解。这种解耦带来的好处是显而易见的，它让系统更加健壮和灵活。
策略模式在算法族管理上的优势体现在哪里？
策略模式在管理“算法族”方面有着天然的优势。所谓“算法族”，指的是一组完成相同目标，但内部实现方式各异的算法。比如，排序算法（冒泡、快排、归并）、图像处理算法（模糊、锐化、灰度化）、路由算法（最短路径、负载均衡）等等。
策略模式允许你将这些相关的算法封装在一个共同的接口之下，使得它们可以互换使用。这种优势主要体现在以下几个方面：
- 易于扩展和维护：当出现新的算法需求时，你只需要实现新的具体策略类，而无需修改现有的任何代码。这符合“开闭原则”，极大地降低了维护成本和引入新bug的风险。比如，你的系统现在支持冒泡排序，未来想引入快速排序，只需添加一个QuickSortStrategy，而不用改动调用排序的地方。
- 运行时算法切换：策略模式使得在运行时动态选择或切换算法成为可能。例如，一个报告生成器可能需要根据用户选择的格式（PDF、excel、html）来导出数据。每种导出格式都是一个具体策略，报告生成器根据用户选择动态加载相应的策略。
- 避免代码重复和臃肿：如果没有策略模式，你可能会在一个方法中包含所有算法的实现，并通过条件语句来选择执行哪一个。这会导致方法体庞大，逻辑复杂，难以阅读和测试。策略模式将每个算法封装在独立的类中，使得代码结构清晰，每个类只负责单一的职责。
- 提高代码的复用性：一旦一个算法被封装成一个策略，它就可以在任何需要它的上下文中使用，而不仅仅局限于最初设计的那个场景。这促进了代码的模块化和复用。
在我看来，策略模式并非仅仅是“消除if-else”的银弹，它更深层次的意义在于提供了一种清晰、优雅的方式来组织和管理那些行为上一致但实现上各异的业务逻辑。它强制你思考和抽象你的“行为”，从而构建出更加灵活、可适应变化的系统架构。当然，任何模式都有其适用场景，如果你的“算法”只有一个，或者极少变化，那么引入策略模式可能会显得过度设计。但对于那些“多变的行为”，它绝对是值得你认真考虑的设计利器。
