策略模式实战：用Java 8 Lambda将if-else改造成插件盒式重构

说真的你有多久没在自己的代码里见过这种场景了一个方法从头到尾全是 if-else一个分支接一个分支每来一个新需求就在后面再挂一个 else if。写法上没什么技术含量但代码量越滚越大改起来越来越心虚看着看着你就想骂人。今天这篇就聊透一件事怎么用策略模式把这段恶心的 if-else 改成“插件盒”式的结构让加需求只加类、不改旧代码。策略模式不是高深理论就是面向对象里那个经典的“把行为封装成独立算法、运行时自由替换”的套路配合 Java 8 的 Lambda 和函数式接口写起来会比教科书的例子顺眼得多。内容既适合刚入门的同学搞懂策略模式的核心思想也适合有几年经验、正想重构老代码的朋友直接拿来参考。我尽量把设计思路、代码落地、踩坑记录都写全毕竟这类重构真正复杂的从来不是语法而是你到底在什么时机、用什么力度去动那堆“历史包袱”。1. 项目背景从一段“无法直视”的 if-else 说起1.1 为什么 if-else 会被写出“山”来我在很多项目里见过同一种“代码事故现场”一个订单结算方法前面先是判断订单状态再判断用户类型接着判断支付渠道往下又是会员等级、优惠券、活动类型……每一层都是 if-else层层嵌套下来一个方法几百行滚动条都快拉一个屏幕。这种代码不是某个新人一夜之间写出来的绝大多数是“长”出来的。产品第一次提需求你写了个 if第二次加渠道你复制粘贴改成 else if第三次加规则你在最外层又套了一层 if第四次急着上线你实在没时间整理就在方法末尾继续塞。每一次改动单看起来都很小但一年下来这个方法就成了“屎山”的起点。我自己就接过一个零售系统的订单计算模块光一个calPrice方法里面有 14 个分支分别处理普通用户、会员用户、铂金会员、不同支付渠道的折扣、满减活动、会员日双倍积分……每次需求评审的时候产品经理一说“增加一个渠道”我脑子嗡的一声因为我知道改哪里、怎么改但更知道改完还得拿 10 多个历史 case 去回归生怕动了一个分支影响了另一个。这个场景应该很多人有共鸣。if-else 本身不是错错的是它承担的职责太多了把一个“选择算法”的动作和“执行算法”的逻辑全搅在一起。你今天看着它是一个判断明天产品告诉你逻辑要改你又要捋一遍这个判断在哪个层级、影响哪些分支。这本质上是“行为的变化”没有独立出来全被硬编码进了流程代码里。1.2 策略模式到底在解决什么问题策略模式的意图特别朴素定义一组算法把它们一个个封装起来并且使它们可以相互替换。上面那个订单计算的例子每个 if 分支里其实就是一套算法比如“普通用户按原价算”“会员用户打九折”“铂金会员打八折再送优惠券”这些算法只是入口条件不同它们的输入、输出结构其实是高度一致的。策略模式把这种结构做了三层划分第一层是策略接口约定好输入输出相当于定义了“插件必须长什么样”第二层是具体策略每个实现类封装一个算法相当于一个个具体的“插件”第三层是上下文它持有一个策略引用业务代码只面向接口编程运行时再把具体的策略注入进去。这样一拆if-else 就没了落脚点。原来那些条件判断本质上是从一堆算法里“挑一个出来执行”策略模式把这个挑选的动作也解耦出去了。你可以用 Map 来映射条件到策略可以用工厂来创建策略也可以用注解加反射自动注册形式很多但核心都是同一个思想算法之间彼此独立业务层不关心算法细节。1.3 “插件盒”这个比喻背后藏着开闭原则题目里说“给你的代码装个插件盒”这个比喻真的很贴切。你想象一下一个电源排插上面有各种插孔新买的电器只要能插进去就能用你不需要去改排插内部的线路。策略模式里的“插件盒”就是上下文和策略注册表具体策略就是那个电器。开闭原则就说一句话对扩展开放对修改关闭。if-else 代码违背的就是这条原则你每加一个分支都必须打开那个几百行的方法去改而策略模式的代码你每加一种算法只需要新写一个策略实现类然后在注册表里登记一下原来的方法一个字都不用动。这带来的最大好处不是“代码看起来高级”而是“犯错的机会变少了”。任何一段还在被业务使用的代码每次改动都是风险每多改一行线上出问题的概率就高一分。策略模式把“新增行为”变成“新增文件”而不是“修改旧逻辑”等于把风险隔离在一个新类里回归成本大大降低。这一点工作几年的人体会最深很多重构的价值不在性能而在降低未来维护的恐惧感。2. 整体设计策略模式怎么变成“插件盒”2.1 从 if-else 到策略模式的映射关系实操之前先把改造思路的映射关系理清楚这样你写代码的时候才知道每一步在干什么。老话讲“磨刀不误砍柴工”重构这类事情最忌讳上手就敲代码先画清楚对应关系心里才有底。我习惯用一个简单的表格来做改造前的需求梳理原 if-else 分支判断条件核心行为策略抽象策略实现类if (payType WECHAT)支付渠道微信渠道结算PayStrategyWechatPayStrategyelse if (payType ALIPAY)支付渠道支付宝渠道结算PayStrategyAlipayPayStrategyelse if (memberLevel GOLD)会员等级黄金会员折扣DiscountStrategyGoldDiscountStrategyelse if (activity FULL_REDUCE)活动类型满减优惠ActivityStrategyFullReduceStrategy做这个表格的时候你会发现自己对业务的理解会变得异常清晰哪些分支其实是同一个维度的“算法族”哪些分支只是另一个分支里的内部细节。这一步做完策略的粒度自然就出来了。这里要强调一个点不是所有 if-else 都要消灭。如果只是两三种固定情况的简单判断硬套策略模式反而过度设计。策略模式的适用信号主要有三个分支数量持续增长、每个分支内的算法都有一定复杂度、算法有着相同形态的输入输出。三个条件都满足才值得动手否则你只是在给代码增加无意义的类项目经理看到那堆“策略类”同样会骂人。2.2 方案选型为什么是策略而不是别的模式不少同学可能听说过模板方法、状态模式、责任链模式它们表面上都和“分支逻辑”相关实际解决问题角度完全不同。做设计的时候选错模式比不选模式更糟糕。模板方法解决的是“同一套流程骨架部分步骤有变化”强调的是把不变的部分写在父类里可变的部分留给子类去重写。如果你那些分支里的代码只是某几步不同前后流程都一致模板方法更合适。策略模式则相反它面对的“整个算法”都是可替换的没有固定骨架的约束。状态模式初看和策略模式几乎一样核心区别在于策略模式里的策略是被外部主动选择的调用方知道自己在用什么策略状态模式里的“状态”是对象内部自动流转的外部一般不感知。订单状态从“待支付”变“已支付”再变“已完成”这是状态模式的地盘手续费按不同支付渠道计算这是策略模式的地盘。责任链模式适合“多个处理器按顺序处理拿到结果才停止”的场景它用来消除的是“连续多次 if 判断谁能处理”的问题。如果需求是“同一笔订单要同时享受支付折扣、会员折扣、活动满减”这是多个策略的“组合叠加”不是责任链的“链式传递”。本篇文章后面会单独讲组合策略的写法那也是策略模式实战里大家最容易卡住的地方。我用一个再生活化一点的类比奖励员工的时候全公司流程都是“提报—审批—发钱”中间审批环节有的部门是主管批有的部门是总监批这是模板方法员工之前是外包现在转正了内部状态变了权限跟着变这是状态模式一个审批单层层上报直到够级别的人拍板这是责任链而业务员给客户报价不同客户等级用不同折扣计算规则这是策略模式。2.3 策略模式不是万能药适用边界要心里有数我见过有人把一个 5 个分支、每分支 3 行代码的方法硬生生拆成 5 个策略类外加一堆工厂注册代码新增了 20 来行跑了一堆单测最后发现需求又改回原来的直白写法了。这就是典型的“用大炮打蚊子”。策略模式有它自己的成本类数量增加项目结构变复杂策略的注册、获取需要一套机制如果做得太重调试起来反而费劲团队里如果有人不熟悉这个模式他可能会继续在策略实现类里写 if-else把问题换个地方藏起来。所以动手之前先问自己几个问题这段 if-else 是不是有超过 5 个且还在增加的分支每个分支是不是都有独立且完整的算法逻辑分支选择的条件和使用场景是不是足够稳定如果答案都是否定的那这个“插件盒”留给以后再说。如果是肯定的那就大胆做下面的方案基本可以无脑抄。另外一个常见误区是策略模式只适合 Java 这类纯面向对象语言。其实不是C、C#、Python、JavaScript 全都可以写策略模式Java 8 只是让这个模式写起来更紧凑了而已。README 里提 Java 8是因为 Lambda 和函数式接口能把“一个接口只有一个方法”那部分样板代码大幅简化但这不影响策略模式思想的通用性。3. 实操Java 8 标准策略模式的完整落地3.1 定义策略接口先从“会变的地方”开始抽取理论讲再多终究要落到代码上。下面我以一个订单结算系统为例走一遍完整的策略化改造流程。这套流程是我在实际项目里反复验证过的写上来的版本是我个人比较喜欢的“稳中带简”风格不会为了炫技而上太多反射、字节码之类的重型武器。第一步从“会变的地方”抽接口。在订单结算里会变的是“价格计算规则”所以我们定义一个价格计算的策略接口。public interface PriceCalculator { /** * 根据订单信息和上下文计算订单最终价格 * * param order 订单信息 * return 计算后的订单价格 */ PriceResult calculate(OrderInfo order); }这个接口里只有主动词和业务对象不要夹带任何实现细节。接口的方法个数也尽量控制在 1 到 3 个超过 3 个建议想想是不是做成了大类。策略模式的接口是给“算法”做门面的门面越薄各个实现类之间的差异越容易体现出来后续写组合策略的时候也越好处理。如果项目里之前没有任何 DTO先补一个OrderInfo和PriceResult别让策略方法传一堆零散参数。参数太多的时候新增策略要传参、改参数列表等于把变更又反向捅回了所有实现类里。把入参、出参都包成对象会让策略接口长期保持稳定这一点在实际项目里收益非常明显。public class OrderInfo { private BigDecimal originalPrice; private String payType; private String memberLevel; private ListString activityIds; private BigDecimal memberDiscount; private BigDecimal activityDiscount; // getter / setter 省略 } public class PriceResult { private BigDecimal finalPrice; private String detailDesc; // getter / setter 省略 }3.2 传统实现类写法 vs Java 8 Lambda 写法接口定义好之后接下来就是写各种各样的策略实现类。如果你还是习惯传统面向对象写法那就老老实实写一个类实现接口把算法逻辑放进方法里。public class NormalPriceCalculator implements PriceCalculator { Override public PriceResult calculate(OrderInfo order) { BigDecimal price order.getOriginalPrice(); PriceResult result new PriceResult(); result.setFinalPrice(price); result.setDetailDesc(普通用户原价); return result; } } public class GoldMemberPriceCalculator implements PriceCalculator { private static final BigDecimal DISCOUNT_RATE new BigDecimal(0.85); Override public PriceResult calculate(OrderInfo order) { BigDecimal price order.getOriginalPrice().multiply(DISCOUNT_RATE); PriceResult result new PriceResult(); result.setFinalPrice(price.setScale(2, RoundingMode.HALF_UP)); result.setDetailDesc(黄金会员85折); return result; } }这么写的好处是好理解、好测试每个策略类都是一个可以独立运行的最小单元。缺点也很明显如果一个策略算法很简单只有一行乘法那你也要为它专门开一个类、一个文件写四个方法类文件的数量会蹭蹭往上涨。这时候 Java 8 的 Lambda 和函数式接口就派上用场了。因为PriceCalculator接口只有一个抽象方法它天然就是一个函数式接口我们完全可以用 Lambda 表达式直接定义策略。你可以把策略注册表定义成一个 Map用枚举或字符串作为 key用 Lambda 或方法引用作为 value。import java.math.BigDecimal; import java.util.EnumMap; import java.util.Map; import java.util.function.Function; public enum CalcRule { NORMAL, GOLD, PLATINUM } public class PriceCalculatorRegistry { private final MapCalcRule, FunctionOrderInfo, PriceResult ruleMap new EnumMap(CalcRule.class); public PriceCalculatorRegistry() { // 注册简单策略直接使用 Lambda ruleMap.put(CalcRule.NORMAL, order - { PriceResult result new PriceResult(); result.setFinalPrice(order.getOriginalPrice()); result.setDetailDesc(普通用户原价); return result; }); ruleMap.put(CalcRule.GOLD, this::calcGoldPrice); ruleMap.put(CalcRule.PLATINUM, order - calcByRate(order, new BigDecimal(0.80))); } public PriceResult calculate(CalcRule rule, OrderInfo order) { FunctionOrderInfo, PriceResult calculator ruleMap.get(rule); if (calculator null) { throw new IllegalArgumentException(Unsupported calc rule: rule); } return calculator.apply(order); } private PriceResult calcGoldPrice(OrderInfo order) { return calcByRate(order, new BigDecimal(0.85)); } private PriceResult calcByRate(OrderInfo order, BigDecimal rate) { BigDecimal price order.getOriginalPrice().multiply(rate) .setScale(2, RoundingMode.HALF_UP); PriceResult result new PriceResult(); result.setFinalPrice(price); result.setDetailDesc(折扣率 rate.toPlainString()); return result; } }这段代码里this::calcGoldPrice是方法引用本质上就是 Lambda 的另一种写法。多写几次你就知道什么时候用 Lambda、什么时候用方法引用了表达式短直接 Lambda表达式长或者是某个现成类的方法用方法引用更清爽。Java 8 这套“行为参数化”的玩法让策略模式从“写很多类”变成了“填很多函数”极大缓解了类爆炸的问题这也是“Java 8 标准策略模式”为什么会被反复提到的原因。3.3 构建“插件盒”策略容器、注册表与工厂策略类和 Lambda 都只是“插件本身”要想成为“插件盒”还差一个容器也就是能够把算法集中管理、按需取用的地方。我的做法是三层结构枚举定义规则编号、注册表集中注册、门面类对外提供统一入口。public enum PayChannel { WECHAT, ALIPAY, UNIONPAY, OFFLINE } public interface PayStrategy { PayResult pay(OrderInfo order); } Component public class PayStrategyFacade { private final MapPayChannel, PayStrategy strategyMap new EnumMap(PayChannel.class); public PayStrategyFacade(ListPayStrategy payStrategyList) { for (PayStrategy strategy : payStrategyList) { PayChannel channel strategy.supportChannel(); if (channel ! null) { strategyMap.put(channel, strategy); } } } public PayResult execute(PayChannel channel, OrderInfo order) { PayStrategy strategy strategyMap.get(channel); if (strategy null) { throw new BizException(暂不支持该支付渠道: channel); } return strategy.pay(order); } }注意这个门面类的构造方式我用了 Spring 的依赖注入把所有PayStrategy类型的 Bean 一次性拿进来然后逐个询问“你支持哪个渠道”把它们装进 Map。这种方式在 Spring 项目里特别常见好处是注册完全自动化后续新写一个策略类、加一个Component注解容器自动就把它装进插件盒不需要改任何注册代码。如果你的项目没有 Spring那就自己维护一个静态注册 Map在静态代码块里手动 put或者用反射扫注解实现自动注册。我建议除非策略数量真的很多否则手动 put 也够用了别为了“自动”二字上反射反射会带来类加载顺序、性能、调试成本等问题收益并不总是值得。3.4 多种策略组合同一笔订单命中多个规则怎么办前面讲的都是“一条订单按一个规则计算”但真实业务里同一笔订单往往会同时命中多个规则用户是黄金会员支付走支付宝正好平台有满 200 减 30 的活动这怎么算如果还是按“选一个策略执行”的思路会发现策略模式好像不够用了。其实不是不够用而是策略也可以“组合”。常见做法有两种。第一种是链式组合定义一个新的CompositePriceCalculator它持有多个PriceCalculator按顺序依次对价格处理。这样每个单一策略只负责“自己的那部分折扣”组合策略负责编排先后顺序。public class CompositePriceCalculator implements PriceCalculator { private final ListPriceCalculator calculators; public CompositePriceCalculator(ListPriceCalculator calculators) { this.calculators calculators; } Override public PriceResult calculate(OrderInfo order) { ListPriceResult results new ArrayList(); BigDecimal currentPrice order.getOriginalPrice(); for (PriceCalculator calculator : calculators) { OrderInfo orderSnapshot new OrderInfo(); orderSnapshot.setOriginalPrice(currentPrice); // 根据需要把原订单信息也复制进去 PriceResult result calculator.calculate(orderSnapshot); results.add(result); currentPrice result.getFinalPrice(); } PriceResult combined new PriceResult(); combined.setFinalPrice(currentPrice); combined.setDetailDesc(results.stream() .map(PriceResult::getDetailDesc) .collect(Collectors.joining( ))); return combined; } }第二种是策略上下文扩展在OrderInfo里单独维护一个折扣累计值每个策略都基于“当前折扣后价格”继续计算。这种写法对策略的独立性要求更高策略内部要明白“我接手的价格可能是别人算过一轮的”命名、注释必须清晰否则很容易出现“折扣重复计算”的事故。我个人建议第一版优先用链式组合因为它每个环节都是独立可测的顺序调整也只是改列表顺序排查问题的时候可以像剥洋葱一样一层一层看。等业务稳定了再考虑优化成统一的上下文对象。组合策略还有一个容易踩的坑规则的执行顺序必须有业务依据。比如“先算会员折扣再算满减”和“先算满减再算会员折扣”最终结果很可能不一样。这个顺序不要写在代码里最好是配置化的否则每次调整顺序又要改代码、发布。配置中心、数据库规则表、甚至一个有序的规则编号字段都能做关键是把“顺序”从代码里抽离出去。4. 实战案例订单结算系统的策略化改造全过程4.1 原始 if-else 代码长什么样先展示一段有代表性的“反面教材”模拟很多老系统里订单价格计算的原始代码。这段代码不是我编的是很多真实项目的浓缩版只是把渠道名和折扣率随意替换了。public class OrderPriceService { public PriceResult calculate(OrderInfo order, String userType, String payType, String activityId) { BigDecimal price order.getOriginalPrice(); String detail ; // 第一层会员类型判断 if (NORMAL.equals(userType)) { detail 普通会员原价; } else if (GOLD.equals(userType)) { price price.multiply(new BigDecimal(0.85)); detail 黄金会员85折; } else if (PLATINUM.equals(userType)) { price price.multiply(new BigDecimal(0.80)); detail 铂金会员8折; } else { throw new BizException(未知会员类型: userType); } // 第二层支付渠道判断不同渠道额外减几块钱 if (WECHAT.equals(payType)) { price price.subtract(new BigDecimal(0.5)); detail detail 微信支付减0.5; } else if (ALIPAY.equals(payType)) { price price.subtract(new BigDecimal(1)); detail detail 支付宝支付减1; } else if (UNIONPAY.equals(payType)) { // 银联不优惠 } else { throw new BizException(未知支付渠道: payType); } // 第三层活动判断满减活动 if (activityId ! null FULL_200_REDUCE_30.equals(activityId)) { if (price.compareTo(new BigDecimal(200)) 0) { price price.subtract(new BigDecimal(30)); detail detail 满200减30; } } price price.setScale(2, RoundingMode.HALF_UP); PriceResult result new PriceResult(); result.setFinalPrice(price); result.setDetailDesc(detail); return result; } }这段代码有三个经典痛点。第一可读性差三层 if-else 嵌套理解这段逻辑得同时记住三个判断维度第二脆弱任何一层规则调整都可能影响下层的计算结果回归测试必须覆盖所有分支组合第三扩展困难产品说“加一个抖音支付渠道满 50 减 5”你又得在第二个 if 后面加一个 else if然后祈祷自己没看漏层级。4.2 改造后的策略代码结构改造后的结构分四块计算策略接口、各会员折扣策略、各支付渠道策略、活动策略。每个策略只关心自己的那一步最后用一个组合器按顺序把它们串起来。public interface StepCalculator { // 返回一个描述供明细展示 String stepDesc(); // 对传入价格做本步骤的处理 BigDecimal apply(BigDecimal currentPrice, OrderInfo order); }Component public class GoldMemberStep implements StepCalculator { public static final String USER_TYPE_GOLD GOLD; Override public String stepDesc() { return 黄金会员85折; } Override public BigDecimal apply(BigDecimal currentPrice, OrderInfo order) { if (!USER_TYPE_GOLD.equals(order.getUserType())) { return currentPrice; } return currentPrice.multiply(new BigDecimal(0.85)); } }注意到这个小设计每一个StepCalculator内部会自己判断“我是否适用于这个订单”不适用就原样返回。这样一来组合器就不需要写任何 if-else它只负责按顺序执行策略。Component public class OrderPriceCalculator { private final ListStepCalculator steps; public OrderPriceCalculator(ListStepCalculator steps) { // 按 Spring 中 Order 注解排序确保执行顺序可控 this.steps steps.stream() .sorted(Comparator.comparingInt( step - Optional.ofNullable( step.getClass().getAnnotation(Order.class)) .map(Order::value) .orElse(Integer.MAX_VALUE))) .collect(Collectors.toList()); } public PriceResult calculate(OrderInfo order) { BigDecimal finalPrice order.getOriginalPrice(); ListString detailList new ArrayList(); for (StepCalculator step : steps) { BigDecimal before finalPrice; finalPrice step.apply(finalPrice, order); if (before.compareTo(finalPrice) ! 0) { detailList.add(step.stepDesc()); } } PriceResult result new PriceResult(); result.setFinalPrice(finalPrice.setScale(2, RoundingMode.HALF_UP)); result.setDetailDesc(detailList.stream().collect(Collectors.joining( ))); return result; } }这样改完原来的OrderPriceService整段逻辑变成了三件事把OrderInfo喂给OrderPriceCalculator拿到PriceResult完事。新加一个渠道、新加一种折扣都只新增一个StepCalculator实现类用Order注明执行顺序不需要动任何既有代码。4.3 测试验证与性能表现重构完之后最怕的就是“看着没改错实际行为完全不一样”。我把原来的 if-else 版本保留在一个LegacyOrderPriceService里写了一个对比测试用几百组随机订单数据跑同一个 case两边输出必须完全一致否则立刻回查。JUnit 5 的写法大致是这样class PriceCalculatorCompareTest { private final LegacyOrderPriceService legacy new LegacyOrderPriceService(); private final OrderPriceCalculator current buildCurrent(); Test void compareWithLegacyForRandomOrders() { for (int i 0; i 1000; i) { OrderInfo order RandomOrderFactory.create(); PriceResult expect legacy.calculate(order, order.getUserType(), order.getPayType(), order.getActivityId()); PriceResult actual current.calculate(order); assertEquals(expect.getFinalPrice(), actual.getFinalPrice(), diff at index i , order order); } } }写这种对比测试花的时间不多但它能帮你兜住 90% 的改坏风险。实测下来重构后的代码在性能上几乎没有损耗因为 Map 查找是 O(1)策略方法调用也只是一次普通的虚方法调用它真正消耗的成本是类加载时的排序和注册这在应用启动时一次性完成可以忽略不计。相比之下原来那段 if-else 每调用一次就会执行一连串字符串比较复杂度并不比 Map 查找低。5. 常见问题与排查技巧实录5.1 常见问题速查表做策略模式改造的时候我在不同项目里踩过的坑和见过别人踩的坑整理成一张速查表方便你到时候对着排查。问题现象可能原因解决思路新加的策略不生效类没加 Component或注册表没扫描到检查 Bean 是否在扫描路径看启动日志策略执行顺序不对没指定 Order或 Order 值冲突统一规划顺序编号留好扩展余量折扣被重复计算多个策略同时修改同一份价格对象策略内复制订单快照或改为返回新对象金额误差、精度问题直接用了 double/float金额计算一律用 BigDecimal保留精度模式策略工厂抛空指针Map 里没找到对应 key工厂里对未知 key 抛出明确业务异常别返回 null组合策略顺序不同、结果不同业务规则本身有先后依赖把执行顺序配置化不要在代码里写死策略类数量爆炸每个简单 Lambda 也建了文件简单策略改用 Lambda/方法引用注册代码评审被质疑过度设计分支少且稳定不需要策略回退到简单写法说明依据后不再固执5.2 避坑经验与独家技巧第一策略接口的入参出参一定要“封闭”尽量都用对象而不是散参数。这个看第一眼不觉得重要等你写了 20 个策略类、突然要加一个“是否节假日”的因素时如果入参是散参数你就得改所有策略的方法签名那酸爽程度不亚于改 if-else 本身。第二组合策略里的“当前价格”对象和“原始订单”对象要分清。我出过一次事故某个策略不小心把OrderInfo.originalPrice改了后续所有策略拿到的都是被改过的价格排查了整整半天。从此我要求所有策略只能返回新价格绝不能修改入参对象实在要改必须先 copy。第三策略注册别用if-else再包一层。我见过有同学把策略模式的类都建好了结果在工厂方法里又写了一串if (A.equals(type)) return new AStrategy();——这不是策略模式这是把 if-else 从业务代码挪到了工厂代码问题一点没解决。要么用 Map 注册要么用 Spring 自动注入把条件选择彻底消灭。第四策略模式配合枚举效果极佳。把枚举作为 Map 的 key比字符串稳妥得多写错有编译检查也不会出现“大小写不一致导致找不到策略”的尴尬。Java 的EnumMap性能还比HashMap好因为它的内部是一个数组按枚举序索引键多的时候优势更明显。第五别把所有规则都塞进“同一个策略接口”。会员折扣、支付渠道、活动满减看着都是“算价格”但它们的职责边界不同、变化的频率不同强行共用一个接口会导致每个策略实现里都要写一堆“不适用就返回原价”的样板代码。拆成MemberDiscountStep、PayChannelStep、ActivityStep几个维度各自维护各自的实现组合时才拼到一起后续改动才真正灵活。这算是策略模式实践里比较容易被忽略的“粒度”问题粒度错了模式再对也很难受。6. 写在最后的一些个人体会6.1 重构前一定要留好回归测试前面那套对比测试的方法是我在几次惨痛的线上事故之后逼自己养成的习惯。代码是你改的但你真的理解所有历史分支吗很多时候那些 if-else 里隐藏着已经没人说得清原因的特殊逻辑——比如“为什么铂金会员在周三不打折”“为什么银联渠道要单独加 0.01 元防重复支付”这些逻辑看一眼代码能看懂表面但背后的历史原因早被人遗忘了。所以我强烈建议任何策略化改造都要先做“行为快照”用一大批覆盖各分支的测试数据把旧代码的输出存下来改造后再对比。这一步不仅保你平安上线还会在新代码出 bug 的时候帮你快速定位是“策略顺序错了”还是“某个策略算法本身算错了”。6.2 策略模式的上限不是代码是你在团队里的沟通你可能已经发现了策略模式的代码本身不难真正难的是怎么让团队接受这种变化。有人会觉得“你是在炫技”“原来的代码虽然乱但能跑”这时候你要做的不是争论而是拿数据说话重构前加一个渠道要改哪几个文件、回归哪些用例重构后加一个渠道只需要新建一个类、补一条测试。把这些放在评审会上比一百句“可维护性”更有说服力。我在团队里推行这套做法的经验是先从增量需求入手不要急着重写老代码。产品提新需求时你就用策略模式写新逻辑老代码不去动等新逻辑在老逻辑旁边跑稳定了再一步步把老分支迁移过来。这种“绞杀式”重构风险低、阻力小大家看着新代码比旧代码清爽自然愿意跟着改。6.3 最后一个小技巧给策略加一个“可追踪标记”线上排查问题的时候策略模式反而会比 if-else 多一步心累你知道走了某个策略但不好定位是哪个。于是我后来在每个策略实现里都返回了一个结构化明细在组合器的detailDesc里把每一步的类名、规则描述、影响金额全部拼出来日志里直接能看出“黄金会员85折 微信支付减0.5 满200减30”的完整链路。这个技巧不值钱但排查问题时极其救命。业务方拿着订单过来说“这个价格不对”你把明细甩给他看一眼就知道哪一步的规则和他预期不符。代码重构的目的本来就不只是让自己写得爽更是让下次改代码的人、查问题的人都能少死几个脑细胞。策略模式做到这个程度才算真正把“插件盒”装到位了。