行为型模式的开篇之作。 如果要用一句话概括策略模式把怎么做的选择从if-else里解放出来。一个接口多个实现运行时随意切换——这就是策略。一、一句话理解策略模式一句话生活类比策略 Strategy定义一组算法封装每个算法让它们可以互相替换导航App最短路线/避开高速/少收费——目标一样策略不同策略模式的核心思想把一个业务目标拆成多种实现方式每种方式封装成一个独立的策略对象。 上下文Context持有策略接口运行时根据需要切换具体策略。三个角色Strategy 接口定义所有策略的统一方法ConcreteStrategy 具体策略每种算法一个类Context 上下文持有策略引用委托执行一句话算法变了我只换策略对象不动主流程。二、小明的if-else地狱2.1 产品经理的一句话故事九月初老板开完会拍着小明的肩膀说 双十一搞个大的优惠玩法要丰富 产品经理第二天甩来一份需求文档 ① 满200减30 ② 全场8折 ③ 秒杀价固定价格 ④ 新人首单5折 ⑤ VIP会员9折 ⑥ 拼团立减15 ⑦ 积分抵扣100积分1元小明看着这份清单心想不就是7个if-else嘛半天搞定。2.2 代码写成了一堵墙两天后代码写完了。public double calculateDiscount(Order order) { String type order.getPromoType(); double price order.getOriginalPrice(); if (FULL_REDUCTION.equals(type)) { // 满200减30 if (price 200) { return price - 30; } return price; } else if (PERCENT_OFF.equals(type)) { // 全场8折 return price * 0.8; } else if (FLASH_SALE.equals(type)) { // 秒杀价 return order.getFlashSalePrice(); } else if (NEW_USER.equals(type)) { // 新人首单5折 if (userService.isNewUser(order.getUserId())) { return price * 0.5; } return price; } else if (VIP.equals(type)) { // VIP会员9折 if (userService.isVip(order.getUserId())) { return price * 0.9; } return price; } else if (GROUP_BUY.equals(type)) { // 拼团立减15 if (groupBuyService.isInGroup(order.getGroupId())) { return price - 15; } return price; } else if (POINTS.equals(type)) { // 积分抵扣 int points userService.getPoints(order.getUserId()); double deduction points / 100.0; return Math.max(price - deduction, 0); } else { return price; } }方法体80行。加上各种辅助判断逻辑整个类超过500行。问题来了① 测试同事崩溃每加一种策略所有分支都要重新回归测试 ② 产品经理又来了再加一个直播专享价再加一个品类专属折扣… ③ 运营说满减规则要改成阶梯式的满100减10满200减30满500减80 ④ 小明每次改代码都怕不小心改坏了别的分支这就是典型的违反开闭原则每次新增策略都要修改这个核心方法。改得越多Bug越多。三、策略模式重构3.1 第一步抽出接口小明想清楚了每种优惠算法本质上都是输入原价输出折后价。// 策略接口统一的方法签名 public interface PromotionStrategy { /** * 计算优惠后价格 * param order 订单信息 * return 优惠后价格 */ double calculate(Order order); /** * 策略类型标识用于工厂匹配 */ String getType(); }3.2 第二步每个策略一个类// 策略1满减 public class FullReductionStrategy implements PromotionStrategy { Override public double calculate(Order order) { double price order.getOriginalPrice(); if (price 200) { return price - 30; } return price; } Override public String getType() { return FULL_REDUCTION; } } // 策略2折扣 public class PercentOffStrategy implements PromotionStrategy { Override public double calculate(Order order) { return order.getOriginalPrice() * 0.8; } Override public String getType() { return PERCENT_OFF; } } // 策略3秒杀 public class FlashSaleStrategy implements PromotionStrategy { Override public double calculate(Order order) { return order.getFlashSalePrice(); } Override public String getType() { return FLASH_SALE; } } // 策略4新人首单 public class NewUserStrategy implements PromotionStrategy { Autowired private UserService userService; Override public double calculate(Order order) { if (userService.isNewUser(order.getUserId())) { return order.getOriginalPrice() * 0.5; } return order.getOriginalPrice(); } Override public String getType() { return NEW_USER; } } // ... 其他策略类类似每个类只做一件事✅关键变化每个策略类只负责一种优惠算法。 改满减规则只改 FullReductionStrategy 一个类其他纹丝不动。 新人首单逻辑有Bug只影响 NewUserStrategy不会波及VIP和拼团。3.3 第三步用Map注册表消灭if-else策略类写好了但选择逻辑怎么办还是得 if-else 判断 type 然后 new 对应的策略不。用Map注册表。Component public class PromotionContext { // 策略注册表type → 策略实例 private final MapString, PromotionStrategy strategyMap new HashMap(); // Spring 自动注入所有 PromotionStrategy 实现类 Autowired public PromotionContext(ListPromotionStrategy strategies) { for (PromotionStrategy strategy : strategies) { strategyMap.put(strategy.getType(), strategy); } } /** * 执行优惠计算 * 一行代码搞定没有 if-else */ public double applyPromotion(Order order) { PromotionStrategy strategy strategyMap .get(order.getPromoType()); if (strategy null) { log.warn(未知优惠类型: {}, order.getPromoType()); return order.getOriginalPrice(); // 默认原价 } return strategy.calculate(order); } }这段代码的精髓① Spring 启动时自动扫描所有 PromotionStrategy 的实现类注入到 List 里 ② 构造函数里遍历 List以 getType() 为 key 注册到 Map ③ 调用时一行 get(type) 就拿到对应策略** 零 if-else**3.4 效果加新策略只要5分钟故事十月中旬产品经理又来找小明 双十一加了直播渠道要支持直播专享价。 以前改500行的核心方法加一个 else if 分支然后全量回归测试。 现在**第一步 **新建一个类public class LiveStreamStrategy implements PromotionStrategy { Override public double calculate(Order order) { // 直播专享价原价减20最低1元 double price order.getOriginalPrice(); return Math.max(price - 20, 1.0); } Override public String getType() { return LIVE_STREAM; } }**第二步 **加个 Component 注解。完事了。Spring 启动时自动扫描、自动注册。PromotionContext 里的 strategyMap 自动多了一条 LIVE_STREAM 的记录。小明泡了杯茶对产品经理说上了。产品经理不需要改别的代码小明不需要。四、对比一下维度if-else 版本策略模式版本新增策略修改核心方法加 else if新建一个类加 Component修改策略在500行代码里定位容易改错改一个类影响范围明确单元测试要覆盖所有分支每个策略类独立测试代码行数1个方法80行整个类500行每个策略类20-30行开闭原则❌ 违反修改已有代码✅ 符合扩展新类不改旧代码运行时切换需要重新调方法换策略对象就行五、策略模式的代价策略模式不是银弹。它也有代价5.1 类数量膨胀7种优惠 7个策略类。如果优惠类型有20种就是20个类。但换个角度想** 20个小类 vs 1个2000行的大类你选哪个**5.2 客户端必须知道所有策略调用方需要知道有哪些策略可选。但这个问题已经被 Map 注册表解决了——前端传 type后端自动匹配。5.3 策略之间不能共享逻辑如果多个策略有相同的判断逻辑比如都要检查用户身份可以抽一个抽象基类// 抽象策略基类共享通用逻辑 public abstract class AbstractPromotionStrategy implements PromotionStrategy { Autowired protected UserService userService; // 通用方法检查是否可用 protected boolean isAvailable(Order order) { return order ! null order.getOriginalPrice() 0; } } // 具体策略继承抽象基类 public class VipStrategy extends AbstractPromotionStrategy { Override public double calculate(Order order) { if (!isAvailable(order)) return 0; if (!userService.isVip(order.getUserId())) { return order.getOriginalPrice(); } return order.getOriginalPrice() * 0.9; } Override public String getType() { return VIP; } }策略 模板方法 组合拳抽象基类提供通用骨架模板方法子类覆写差异部分。 这个组合在框架设计中非常常见。后面讲模板方法模式时会展开说。六、Java 8 函数式简化如果策略只有一个方法绝大多数情况可以用 Lambda 表达式直接简化// 不需要定义接口和类直接用函数 public class PromotionEngine { // 策略注册表type → 计算函数 private static final MapString, FunctionOrder, Double STRATEGIES new HashMap(); static { // 满减满200减30 STRATEGIES.put(FULL_REDUCTION, order - order.getOriginalPrice() 200 ? order.getOriginalPrice() - 30 : order.getOriginalPrice()); // 8折 STRATEGIES.put(PERCENT_OFF, order - order.getOriginalPrice() * 0.8); // 秒杀 STRATEGIES.put(FLASH_SALE, order - order.getFlashSalePrice()); } public static double apply(String type, Order order) { FunctionOrder, Double strategy STRATEGIES.getOrDefault(type, o - o.getOriginalPrice()); // 默认原价 return strategy.apply(order); } }✅函数式策略的优势不用写接口、不用写类一个 Lambda 搞定代码量减少80%适合简单策略无状态、无外部依赖⚠️但也有局限策略逻辑复杂时超过10行Lambda 可读性下降需要注入 Service 时如查用户信息Lambda 不方便不方便做单元测试建议简单策略用 Lambda复杂策略用接口类。七、策略模式在 JDK 中的应用你以为策略模式很高大上其实你天天在用7.1 Arrays.sort() 的 ComparatorString[] names {Charlie, Alice, Bob}; // 策略1按字母排序 Arrays.sort(names, Comparator.naturalOrder()); // 策略2按字母倒序 Arrays.sort(names, Comparator.reverseOrder()); // 策略3按长度排序 Arrays.sort(names, Comparator.comparingInt(String::length)); sort() 方法不关心你怎么排它只调 Comparator.compare()。排序算法是固定的比较策略是你传的。这就是策略模式。7.2 ThreadFactory// 线程池用 ThreadFactory 策略来创建线程 ExecutorService pool Executors.newFixedThreadPool( 10, r - { Thread t new Thread(r); t.setName(my-pool- t.getId()); t.setDaemon(true); // 守护线程 return t; } );线程池不关心线程怎么创建你传什么策略它就怎么创建。八、软考高频考点考点内容模式分类行为型模式核心意图定义一系列算法封装每个算法使它们可以互相替换三个角色Strategy策略接口、ConcreteStrategy具体策略、Context上下文核心原则开闭原则对扩展开放对修改关闭常见搭配策略 工厂Map注册表、策略 模板方法抽象基类优点① 避免多重条件语句 ② 符合开闭原则 ③ 算法可独立测试和复用缺点① 策略类数量增多 ② 客户端需了解所有策略 ③ 仅适用于算法变体场景经典案例排序的Comparator、支付方式选择、优惠策略引擎易混淆策略 vs 状态策略是主动选择状态是自动切换软考高频真题某电商系统支持多种促销策略要求新增促销方式时不修改已有代码。应采用设计模式。 → 答案** 策略模式** 策略模式的主要优点是 → 答案** 符合开闭原则可以在不修改原有代码的情况下增加新算法**九、策略 vs 状态别搞混了策略模式和状态模式长得很像都是接口多个实现但本质完全不同维度策略模式状态模式下篇预告谁选择客户端主动选择对象内部自动切换是否感知客户端知道用的哪个策略客户端不关心当前状态各策略是否独立完全独立互不知道状态之间知道彼此负责切换典型场景支付方式、优惠算法订单状态机、审批流程一句话区分**策略模式 **你去餐厅主动选择吃川菜还是粤菜。 **状态模式 **订单从待支付到已发货自动流转你不用管。十、总结策略模式是行为型模式的第一块基石也是最实用的模式之一。策略模式核心要点**问题 **多种算法用 if-else 堆在一起改一个影响全部**方案 **每种算法封装成独立的策略类通过接口统一调用**进阶 **策略 工厂Map 注册表消灭选择逻辑**简化 **Java 8 Lambda 适合简单策略**搭配 **抽象基类 模板方法共享通用逻辑**本质 **客户端主动选择算法运行时可切换行为型模式的旅程从策略开始。接下来小明还会遇到订单状态机状态模式事件广播系统观察者模式审批流程引擎模板方法 责任链……每一个都是他从小白进阶到架构师的必经之路。
行为型模式的开篇之作。 如果要用一句话概括策略模式把怎么做的选择从if-else里解放出来。一个接口多个实现运行时随意切换——这就是策略。一、一句话理解策略模式一句话生活类比策略 Strategy定义一组算法封装每个算法让它们可以互相替换导航App最短路线/避开高速/少收费——目标一样策略不同策略模式的核心思想把一个业务目标拆成多种实现方式每种方式封装成一个独立的策略对象。 上下文Context持有策略接口运行时根据需要切换具体策略。三个角色Strategy 接口定义所有策略的统一方法ConcreteStrategy 具体策略每种算法一个类Context 上下文持有策略引用委托执行一句话算法变了我只换策略对象不动主流程。二、小明的if-else地狱2.1 产品经理的一句话故事九月初老板开完会拍着小明的肩膀说 双十一搞个大的优惠玩法要丰富 产品经理第二天甩来一份需求文档 ① 满200减30 ② 全场8折 ③ 秒杀价固定价格 ④ 新人首单5折 ⑤ VIP会员9折 ⑥ 拼团立减15 ⑦ 积分抵扣100积分1元小明看着这份清单心想不就是7个if-else嘛半天搞定。2.2 代码写成了一堵墙两天后代码写完了。public double calculateDiscount(Order order) { String type order.getPromoType(); double price order.getOriginalPrice(); if (FULL_REDUCTION.equals(type)) { // 满200减30 if (price 200) { return price - 30; } return price; } else if (PERCENT_OFF.equals(type)) { // 全场8折 return price * 0.8; } else if (FLASH_SALE.equals(type)) { // 秒杀价 return order.getFlashSalePrice(); } else if (NEW_USER.equals(type)) { // 新人首单5折 if (userService.isNewUser(order.getUserId())) { return price * 0.5; } return price; } else if (VIP.equals(type)) { // VIP会员9折 if (userService.isVip(order.getUserId())) { return price * 0.9; } return price; } else if (GROUP_BUY.equals(type)) { // 拼团立减15 if (groupBuyService.isInGroup(order.getGroupId())) { return price - 15; } return price; } else if (POINTS.equals(type)) { // 积分抵扣 int points userService.getPoints(order.getUserId()); double deduction points / 100.0; return Math.max(price - deduction, 0); } else { return price; } }方法体80行。加上各种辅助判断逻辑整个类超过500行。问题来了① 测试同事崩溃每加一种策略所有分支都要重新回归测试 ② 产品经理又来了再加一个直播专享价再加一个品类专属折扣… ③ 运营说满减规则要改成阶梯式的满100减10满200减30满500减80 ④ 小明每次改代码都怕不小心改坏了别的分支这就是典型的违反开闭原则每次新增策略都要修改这个核心方法。改得越多Bug越多。三、策略模式重构3.1 第一步抽出接口小明想清楚了每种优惠算法本质上都是输入原价输出折后价。// 策略接口统一的方法签名 public interface PromotionStrategy { /** * 计算优惠后价格 * param order 订单信息 * return 优惠后价格 */ double calculate(Order order); /** * 策略类型标识用于工厂匹配 */ String getType(); }3.2 第二步每个策略一个类// 策略1满减 public class FullReductionStrategy implements PromotionStrategy { Override public double calculate(Order order) { double price order.getOriginalPrice(); if (price 200) { return price - 30; } return price; } Override public String getType() { return FULL_REDUCTION; } } // 策略2折扣 public class PercentOffStrategy implements PromotionStrategy { Override public double calculate(Order order) { return order.getOriginalPrice() * 0.8; } Override public String getType() { return PERCENT_OFF; } } // 策略3秒杀 public class FlashSaleStrategy implements PromotionStrategy { Override public double calculate(Order order) { return order.getFlashSalePrice(); } Override public String getType() { return FLASH_SALE; } } // 策略4新人首单 public class NewUserStrategy implements PromotionStrategy { Autowired private UserService userService; Override public double calculate(Order order) { if (userService.isNewUser(order.getUserId())) { return order.getOriginalPrice() * 0.5; } return order.getOriginalPrice(); } Override public String getType() { return NEW_USER; } } // ... 其他策略类类似每个类只做一件事✅关键变化每个策略类只负责一种优惠算法。 改满减规则只改 FullReductionStrategy 一个类其他纹丝不动。 新人首单逻辑有Bug只影响 NewUserStrategy不会波及VIP和拼团。3.3 第三步用Map注册表消灭if-else策略类写好了但选择逻辑怎么办还是得 if-else 判断 type 然后 new 对应的策略不。用Map注册表。Component public class PromotionContext { // 策略注册表type → 策略实例 private final MapString, PromotionStrategy strategyMap new HashMap(); // Spring 自动注入所有 PromotionStrategy 实现类 Autowired public PromotionContext(ListPromotionStrategy strategies) { for (PromotionStrategy strategy : strategies) { strategyMap.put(strategy.getType(), strategy); } } /** * 执行优惠计算 * 一行代码搞定没有 if-else */ public double applyPromotion(Order order) { PromotionStrategy strategy strategyMap .get(order.getPromoType()); if (strategy null) { log.warn(未知优惠类型: {}, order.getPromoType()); return order.getOriginalPrice(); // 默认原价 } return strategy.calculate(order); } }这段代码的精髓① Spring 启动时自动扫描所有 PromotionStrategy 的实现类注入到 List 里 ② 构造函数里遍历 List以 getType() 为 key 注册到 Map ③ 调用时一行 get(type) 就拿到对应策略** 零 if-else**3.4 效果加新策略只要5分钟故事十月中旬产品经理又来找小明 双十一加了直播渠道要支持直播专享价。 以前改500行的核心方法加一个 else if 分支然后全量回归测试。 现在**第一步 **新建一个类public class LiveStreamStrategy implements PromotionStrategy { Override public double calculate(Order order) { // 直播专享价原价减20最低1元 double price order.getOriginalPrice(); return Math.max(price - 20, 1.0); } Override public String getType() { return LIVE_STREAM; } }**第二步 **加个 Component 注解。完事了。Spring 启动时自动扫描、自动注册。PromotionContext 里的 strategyMap 自动多了一条 LIVE_STREAM 的记录。小明泡了杯茶对产品经理说上了。产品经理不需要改别的代码小明不需要。四、对比一下维度if-else 版本策略模式版本新增策略修改核心方法加 else if新建一个类加 Component修改策略在500行代码里定位容易改错改一个类影响范围明确单元测试要覆盖所有分支每个策略类独立测试代码行数1个方法80行整个类500行每个策略类20-30行开闭原则❌ 违反修改已有代码✅ 符合扩展新类不改旧代码运行时切换需要重新调方法换策略对象就行五、策略模式的代价策略模式不是银弹。它也有代价5.1 类数量膨胀7种优惠 7个策略类。如果优惠类型有20种就是20个类。但换个角度想** 20个小类 vs 1个2000行的大类你选哪个**5.2 客户端必须知道所有策略调用方需要知道有哪些策略可选。但这个问题已经被 Map 注册表解决了——前端传 type后端自动匹配。5.3 策略之间不能共享逻辑如果多个策略有相同的判断逻辑比如都要检查用户身份可以抽一个抽象基类// 抽象策略基类共享通用逻辑 public abstract class AbstractPromotionStrategy implements PromotionStrategy { Autowired protected UserService userService; // 通用方法检查是否可用 protected boolean isAvailable(Order order) { return order ! null order.getOriginalPrice() 0; } } // 具体策略继承抽象基类 public class VipStrategy extends AbstractPromotionStrategy { Override public double calculate(Order order) { if (!isAvailable(order)) return 0; if (!userService.isVip(order.getUserId())) { return order.getOriginalPrice(); } return order.getOriginalPrice() * 0.9; } Override public String getType() { return VIP; } }策略 模板方法 组合拳抽象基类提供通用骨架模板方法子类覆写差异部分。 这个组合在框架设计中非常常见。后面讲模板方法模式时会展开说。六、Java 8 函数式简化如果策略只有一个方法绝大多数情况可以用 Lambda 表达式直接简化// 不需要定义接口和类直接用函数 public class PromotionEngine { // 策略注册表type → 计算函数 private static final MapString, FunctionOrder, Double STRATEGIES new HashMap(); static { // 满减满200减30 STRATEGIES.put(FULL_REDUCTION, order - order.getOriginalPrice() 200 ? order.getOriginalPrice() - 30 : order.getOriginalPrice()); // 8折 STRATEGIES.put(PERCENT_OFF, order - order.getOriginalPrice() * 0.8); // 秒杀 STRATEGIES.put(FLASH_SALE, order - order.getFlashSalePrice()); } public static double apply(String type, Order order) { FunctionOrder, Double strategy STRATEGIES.getOrDefault(type, o - o.getOriginalPrice()); // 默认原价 return strategy.apply(order); } }✅函数式策略的优势不用写接口、不用写类一个 Lambda 搞定代码量减少80%适合简单策略无状态、无外部依赖⚠️但也有局限策略逻辑复杂时超过10行Lambda 可读性下降需要注入 Service 时如查用户信息Lambda 不方便不方便做单元测试建议简单策略用 Lambda复杂策略用接口类。七、策略模式在 JDK 中的应用你以为策略模式很高大上其实你天天在用7.1 Arrays.sort() 的 ComparatorString[] names {Charlie, Alice, Bob}; // 策略1按字母排序 Arrays.sort(names, Comparator.naturalOrder()); // 策略2按字母倒序 Arrays.sort(names, Comparator.reverseOrder()); // 策略3按长度排序 Arrays.sort(names, Comparator.comparingInt(String::length)); sort() 方法不关心你怎么排它只调 Comparator.compare()。排序算法是固定的比较策略是你传的。这就是策略模式。7.2 ThreadFactory// 线程池用 ThreadFactory 策略来创建线程 ExecutorService pool Executors.newFixedThreadPool( 10, r - { Thread t new Thread(r); t.setName(my-pool- t.getId()); t.setDaemon(true); // 守护线程 return t; } );线程池不关心线程怎么创建你传什么策略它就怎么创建。八、软考高频考点考点内容模式分类行为型模式核心意图定义一系列算法封装每个算法使它们可以互相替换三个角色Strategy策略接口、ConcreteStrategy具体策略、Context上下文核心原则开闭原则对扩展开放对修改关闭常见搭配策略 工厂Map注册表、策略 模板方法抽象基类优点① 避免多重条件语句 ② 符合开闭原则 ③ 算法可独立测试和复用缺点① 策略类数量增多 ② 客户端需了解所有策略 ③ 仅适用于算法变体场景经典案例排序的Comparator、支付方式选择、优惠策略引擎易混淆策略 vs 状态策略是主动选择状态是自动切换软考高频真题某电商系统支持多种促销策略要求新增促销方式时不修改已有代码。应采用设计模式。 → 答案** 策略模式** 策略模式的主要优点是 → 答案** 符合开闭原则可以在不修改原有代码的情况下增加新算法**九、策略 vs 状态别搞混了策略模式和状态模式长得很像都是接口多个实现但本质完全不同维度策略模式状态模式下篇预告谁选择客户端主动选择对象内部自动切换是否感知客户端知道用的哪个策略客户端不关心当前状态各策略是否独立完全独立互不知道状态之间知道彼此负责切换典型场景支付方式、优惠算法订单状态机、审批流程一句话区分**策略模式 **你去餐厅主动选择吃川菜还是粤菜。 **状态模式 **订单从待支付到已发货自动流转你不用管。十、总结策略模式是行为型模式的第一块基石也是最实用的模式之一。策略模式核心要点**问题 **多种算法用 if-else 堆在一起改一个影响全部**方案 **每种算法封装成独立的策略类通过接口统一调用**进阶 **策略 工厂Map 注册表消灭选择逻辑**简化 **Java 8 Lambda 适合简单策略**搭配 **抽象基类 模板方法共享通用逻辑**本质 **客户端主动选择算法运行时可切换行为型模式的旅程从策略开始。接下来小明还会遇到订单状态机状态模式事件广播系统观察者模式审批流程引擎模板方法 责任链……每一个都是他从小白进阶到架构师的必经之路。
)
)
