说服力最强的永远是项目里的真实痛点。先别管策略模式的定义多高深想想你有没有写过这样一种 Java 代码一个方法里全是 if-else每加一种新玩法就要打开老方法再补一个分支补着补着方法变成几百行测试用例看着都眼晕。如果你点头了那你需要的就是策略模式。这篇文章面向小白但不会只停留在“什么是策略模式”我会从最原始的痛点场景讲起带你手写一个能运行的最小示例再给出真实项目里最常用的“枚举 Spring 容器”玩法最后把多态原理和实战中常见的坑一次说清楚。看完你就能在项目里落地而且心里明白为什么这么写是对的。1. 策略模式到底在解决什么问题1.1 一段让人头皮发麻的 if-else假设你在维护一个电商订单模块要计算商品优惠后的价格。最开始只有一种满减券代码很清爽public double calculateCouponPrice(Order order) { if (order.getTotalPrice() 100) { return order.getTotalPrice() - 20; } return order.getTotalPrice(); }后来业务扩张加了折扣券、无门槛立减、还有会员专属价。你会发现很多人的第一反应都是继续往同一个方法里堆分支public double calculateCouponPrice(Order order, Integer couponType) { double total order.getTotalPrice(); if (couponType 1) { if (total 100) { return total - 20; } return total; } else if (couponType 2) { return total * 0.8; } else if (couponType 3) { return total - 5; } return total; }问题在哪儿首先是“新增需求要动老代码”。下个月要加“第二件半价”你还是得打开calculateCouponPrice在最底下补一个 else if。改一个稳定的老方法本身就是风险一个不小心影响了满减逻辑线上订单就全算了错账。其次是“判断逻辑和执行逻辑绑在了一起”。这种方法里混杂着“这个单子适用哪种规则”和“这种规则具体怎么算”两件事职责不清晰而且随着分支增多可读性急剧下降。测试呢为了覆盖所有分支你得把每种类型都调用一遍分支的组合一多测试用例数量简直爆炸。这种坏味道在真实项目里非常常见包括后面说的支付方式、消息推送渠道、报表导出格式选择模式是一模一样的。它的本质是一系列算法规则被平铺到一个方法里每次新增算法都得修改既有代码。1.2 用快餐店点餐理解策略模式我们用一个生活化的场景把策略模式讲明白。想象一家快餐店柜台后的服务员脑子像一本厚厚的菜单手册。你说“我要 A 套餐”服务员就开始背A 套餐包含什么、价格多少、怎么打包。餐厅一旦推出 B 套餐、C 套餐服务员就得重新接受培训把新套餐的所有规则背下来。这个服务员对应的就是上面那个又长又乱的大方法所有套餐规则都集中在他的大脑里。现在换成自助点餐机。机器屏幕上有 A、B、C 套餐按钮你按 AA 套餐的程序逻辑自己负责计算价格和下单你按 BB 套餐的另一套程序接管。餐厅出新套餐时只需要在机器里增加一个新的套餐实现点餐机的主体流程、屏幕框架统统不用改动。策略模式就是这套点餐机逻辑的代码版。点餐机是“上下文”套餐按钮对应的逻辑是“具体策略”而“如何生成一单”的统一规则就是“策略接口”。它要解决的正是上面那段 if-else 的核心病根让算法各自成类调用方只依赖一个稳定接口不对具体实现指手画脚。这样新增算法不需要改动老代码这就是设计模式里常说的“开闭原则”的落地。2. 策略模式的三件套和原理2.1 三个角色分别是谁策略模式的角色比很多设计模式都要简洁核心就三个。策略接口Strategy定义一族算法的统一入口。比如“计算优惠后的价格”接口里定义一个方法BigDecimal calculate(OrderInfo order)。它不关心具体怎么算只约定实现类必须提供这个能力。策略接口的存在让调用方能够面向接口编程而不是依赖某一个具体类。具体策略ConcreteStrategy实现策略接口的各个类。满减类、折扣类、立减类各写各的算法彼此独立。新增一种规则就是新增一个实现类。这个方法最大的好处是隔离了变化每个策略的改动只会影响自己不会波及其他策略。上下文Context持有策略接口的引用对外提供统一的执行入口。它相当于点餐机的机器本体内部怎么运行外部不关心外部只知道把策略丢给它然后它可以计算出结果。上下文还可以承载公共逻辑比如参数校验、日志记录、埋点上报这样这些逻辑不会在每个具体策略里重复出现。用一个图意会一下它们的关系客户端创建上下文上下文持有接口引用引用指向某个具体策略调用方法时由具体策略执行算法。// 策略接口 public interface PriceStrategy { BigDecimal calculate(OrderInfo order); } // 具体策略满减 public class FullReductionStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { // 具体满减逻辑 return null; } } // 上下文 public class PriceContext { private PriceStrategy strategy; public PriceContext(PriceStrategy strategy) { this.strategy strategy; } public BigDecimal execute(OrderInfo order) { // 这个地方可以扩展公共逻辑比如日志、校验 return strategy.calculate(order); } }现在你心里应该有了一张粗略地图。接下来要回答一个更关键的问题这样设计凭什么能让代码更好维护2.2 开闭原则和多态才是底层逻辑策略模式不只是一个代码组织技巧它背后站着两个基础机制开闭原则和动态绑定。开闭原则的意思是对扩展开放对修改关闭。当你新增一种“新客立减 10 元”的优惠时按照策略模式的写法你只需要新写一个NewCustomerStrategy实现类然后让工厂或者客户端在需要的时候传进上下文。满减、折扣等已有策略类和上下文的核心流程全都纹丝不动。这就是“对修改关闭”——老代码零触碰风险因此被压到最低。动态绑定则是 Java 语言给策略模式提供的运行时引擎。你在代码里声明的类型是PriceStrategy但实际引用的对象可以是任意一个实现类。JVM 在运行时才会根据对象的真实类型决定调用哪个实现类的方法。正因为有这个机制上下文里的PriceStrategy strategy才能今天指向满减明天指向折扣而上下文自己不需要任何改动。如果你在非面向对象语言里写十几个策略实现类还得靠手动分发策略模式的优势就没这么明显了。还有一个隐藏的重要原则组合优先于继承。策略模式没有让上下文继承某一个具体策略而是通过接口变量持有策略对象这是一种“组合关系”。组合相比继承耦合更低、更灵活。继承是is-a策略模式里上下文和策略是has-a上下文“有一个”策略而不是“是一个”策略。理解了“组合优于继承”你才算真正看懂了策略模式的设计哲学。3. 从零手写一个最小可运行示例3.1 定义策略接口为什么推荐传对象前面理论说多了直接动手写一个能跑的最小示例。工程不需要任何框架JDK 8 以上即可一个接口、三个实现类、一个上下文、一个 main 方法。第一步定义订单信息对象。这里有个容易被新手忽略的好习惯策略接口的参数尽量传一个上下文对象而不是一堆散参。如果接口方法写成BigDecimal calculate(double price, int userLevel, String channel)以后策略需要新增一个“地区编码”参数接口签名要改所有实现类签名都要跟着改那策略模式的好处就被抵消一半。而传一个OrderInfo对象新增字段完全不影响接口public class OrderInfo { private BigDecimal totalPrice; private int userLevel; private String channel; // 构造器、getter/setter 省略 }第二步定义策略接口public interface PriceStrategy { BigDecimal calculate(OrderInfo order); }这里我直接用BigDecimal返回值。真实项目中涉及金额计算别用double这章末尾我也会单独列为禁忌。3.2 实现三种具体策略接下来写三个标准策略满减、折扣、无门槛立减。每个策略类只关心自己的算法不要互相依赖。public class FullReductionStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { BigDecimal total order.getTotalPrice(); // 满 100 减 20 if (total.compareTo(new BigDecimal(100)) 0) { return total.subtract(new BigDecimal(20)); } return total; } }public class DiscountStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { // 打 8 折 return order.getTotalPrice().multiply(new BigDecimal(0.8)); } }public class CashOffStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { BigDecimal result order.getTotalPrice().subtract(new BigDecimal(5)); // 最低不能低于 0 if (result.compareTo(BigDecimal.ZERO) 0) { return BigDecimal.ZERO; } return result; } }写这几个类时有几个细节值得强调。第一满减策略里的阈值和减额我用了字符串构造BigDecimal(100)而不是new BigDecimal(100)也不建议用new BigDecimal(0.8)这种浮点字面量否则会出现无法精确表示的尾数第二每个策略内部逻辑是完全自洽的满减策略里绝不能出现“如果用户是会员走折扣”这种跳转到其他策略的逻辑策略之间必须保持独立否则就破坏了可替换性。3.3 用上下文串起来并测试上下文类负责持有策略引用并且可以在这里加一些所有策略都会用到的公共处理。public class PriceContext { private PriceStrategy strategy; public PriceContext(PriceStrategy strategy) { this.strategy strategy; } public BigDecimal execute(OrderInfo order) { // 公共校验逻辑可以写在这里 return strategy.calculate(order); } }这里我用构造器传入策略而不是暴露 setter 方法。两者的区别我在实际项目中体会很深构造器注入适合一次上下文对应一次策略计算策略相对固定setter 注入则适合同一个上下文在不同阶段切换策略。但要注意如果你用 Spring 管理上下文并且上下文是单例那么成员变量存策略就必须小心因为单例会被多个线程共享策略如果带有请求级状态很容易出并发问题这在我们第六章的避坑部分会展开说。客户端调用public class StrategyDemo { public static void main(String[] args) { OrderInfo order new OrderInfo(); order.setTotalPrice(new BigDecimal(120)); PriceContext context new PriceContext(new FullReductionStrategy()); System.out.println(满减价格: context.execute(order)); context new PriceContext(new DiscountStrategy()); System.out.println(折扣价格: context.execute(order)); context new PriceContext(new CashOffStrategy()); System.out.println(立减价格: context.execute(order)); } }输出分别是 100、96、115和手算一致。现在你亲手跑通了一个完整的策略模式示例。不过别急着开心这个示例里藏着两个问题真实项目里必须解决第一客户端在创建PriceContext时还是在用new FullReductionStrategy()这种方式来选策略等于把 if-else 从算法内部搬到了客户端问题并没有根除第二策略对象都是手动 new 的没有交给 Spring 管理这样策略类里想注入其他依赖就非常麻烦。下一章我们来看工程化的标准解法。4. 真实项目玩法策略模式 枚举 Spring 容器4.1 原生策略模式在项目里的尴尬手动 new 策略的写法在教学示例里没毛病但拿到真实项目里就会碰到两个尴尬处境。第一个尴尬是“选策略的 if-else 依然存在”。用户下单的时候要根据优惠券类型选择执行哪个策略代码大概率长成这样PriceStrategy strategy; if (FULL_REDUCTION.equals(couponType)) { strategy new FullReductionStrategy(); } else if (DISCOUNT.equals(couponType)) { strategy new DiscountStrategy(); } else if (CASH_OFF.equals(couponType)) { strategy new CashOffStrategy(); }写到这里很多人会恍然大悟这不就是换了种写法的 if-else 吗原来的是规则判断现在的是策略选择判断。本质上分支没有被消灭只是挪了个位置。第二个尴尬是 Spring 管理。手动 new 出来的策略不在 Spring 容器里Autowired注入其他服务一概失效。而真实业务里折扣策略可能需要调用户积分服务、风控策略可能需要查黑名单、满减策略可能要读配置中心的阈值。没有容器这些依赖全部无法注入。真正的解法是让 Spring 容器把所有PriceStrategy的实现类自动收集成一个 Map 或 List然后用策略类型去拿对应的策略 Bean。Spring 对接口集合注入有天然支持用起来非常顺手。4.2 用枚举统一管理策略标识要优雅地标识策略优先用枚举而不是魔法字符串。枚举的好处是编译期检查写错类型名编译直接报错而不是运行到那行才发现取了个 null而且枚举天然适合做 switch 和 Map 的 key。public enum PromotionType { FULL_REDUCTION(满减), DISCOUNT(折扣), CASH_OFF(立减); private final String desc; PromotionType(String desc) { this.desc desc; } }接着定义策略接口。为了让策略对象能自报家门我加了一个getType()方法每个实现类返回自己对应的枚举类型。这样做的好处后面会体现工厂不需要依赖 Spring 的 Bean 命名规则而是直接问策略对象“你是什么类型”语义非常清晰。public interface PromotionStrategy { PromotionType getType(); BigDecimal calculate(OrderInfo order); }三个实现类分别加上Component让 Spring 扫描到它们Component public class FullReductionStrategy implements PromotionStrategy { Override public PromotionType getType() { return PromotionType.FULL_REDUCTION; } Override public BigDecimal calculate(OrderInfo order) { // 满减实现 } }DiscountStrategy和CashOffStrategy结构类似不重复贴代码。4.3 用 Spring 自动收集策略 Bean这是整篇文章里最有工程价值的一部分。在 Spring 中你可以直接把一个接口的多个实现类注入到MapString, PromotionStrategy或ListPromotionStrategy中。Spring 会扫描容器内所有该接口的实现 Bean自动填充集合。我们写一个策略工厂Component public class PromotionStrategyFactory { private final ListPromotionStrategy strategyList; Autowired public PromotionStrategyFactory(ListPromotionStrategy strategyList) { this.strategyList strategyList; } public PromotionStrategy getStrategy(PromotionType type) { return strategyList.stream() .filter(strategy - strategy.getType() type) .findFirst() .orElseThrow(() - new IllegalArgumentException(未找到对应的策略: type)); } }细看这段代码工厂内部没有冗余的分支判断而是遍历所有策略通过getType() type找到匹配项。这种写法的扩展性极强以后新增一种优惠只需要新写一个实现类实现PromotionType对应方法然后再在枚举中加一个值。策略工厂一行都不用改调用方一行都不用改。真正做到了“开闭原则”。初学者容易困惑的一个点为什么这里选择注入List而不是MapString, PromotionStrategy如果我注入 Mapkey 是 Bean 的名称类名的默认小驼峰跟枚举名完全不搭还需要额外处理大小写和命名规则。而注入 List 加上getType()方法策略类型信息完全由类自身表达不会因为重构类名或改变 Bean 命名约定而出问题。这是我在项目里迭代之后沉淀下来的经验。4.4 调用方可以干净到什么程度有工厂之后业务代码会简洁到几乎看不出策略的存在。比如订单结算服务Service public class OrderService { private final PromotionStrategyFactory promotionStrategyFactory; Autowired public OrderService(PromotionStrategyFactory promotionStrategyFactory) { this.promotionStrategyFactory promotionStrategyFactory; } public BigDecimal checkout(OrderInfo order, PromotionType promotionType) { PromotionStrategy strategy promotionStrategyFactory.getStrategy(promotionType); return strategy.calculate(order); } }如果后面要做叠加促销你甚至可以写一个 CompositeStrategy内部包一个ListPromotionStrategy循环执行把上一个策略的结果传给下一个。这个变体我们在第五章讲它属于策略模式的扩展玩法不是核心但很常用。如果你觉得为了两行计算逻辑就建一个类文件很浪费还有一个轻量级方案用枚举持有函数式接口。比如在PromotionType枚举里加一个FunctionOrderInfo, BigDecimal calculator字段每个枚举值对应一段 lambda。这样确实能减少类数量代码也紧凑。但是注意一旦策略逻辑超过三行或者需要复用其他 Spring 服务就别硬塞进枚举否则一个隐藏在大段 lambda 里的复杂逻辑反而难以测试和维护。什么时候用独立策略类什么时候用轻量枚举我的判断标准是策略内部是否依赖其他业务服务逻辑是否超过三行。5. 深入原理多态、动态绑定与变体5.1 从多态理解策略模式的运行时行为策略模式为什么能运行时切换算法这个能力完全来自 Java 的动态绑定机制。在你写PromotionStrategy strategy这个引用时编译器的静态类型是接口编译器只会安全地允许你调用PromotionStrategy接口里定义的方法。程序真正运行的时候JVM 会查看这个引用实际指向的对象类型再找到该对象所属类的方法表调用对应实现。这就是“动态绑定”方法调用的目标不是编译期决定的而是运行期决定的。举个具体例子工厂返回一个FullReductionStrategy对象但方法的声明返回类型是PromotionStrategy编译器不知道它的真实类型运行时 JVM 却知道所以执行的是满减的calculate。换一个DiscountStrategy对象同样的代码执行的就是折扣的calculate。策略模式正是充分利用了这个语言特性才做到上下文代码零改动。这里我也想提醒一个容易踩的设计细节策略接口的方法签名一定要尽量稳定。如果方法签名里写死BigDecimal calculate(BigDecimal price, String channel)以后策略需要用户等级、订单明细、地区信息接口就要改所有策略实现类都要同步改。改成传一个上下文对象后接口自身非常稳定新需求只要往上下文里加字段。我见过好几个人因为参数问题反复改策略接口最后抱怨策略模式不好用其实问题出在接口设计上。5.2 标准库里到处都是策略模式学设计模式最有效的辅助方式之一就是在标准库里找现成的例子。Java 标准库最典型的就是java.util.Comparator。Comparator就是经典的策略接口它的compare方法是算法入口。同一组对象排序时你可以传入不同的 Comparator 实现实现按年龄排、按姓名排、按金额排。Collections.sort算法本身完全不关心具体排序规则它只是调用你传入的策略。排序方法相当于上下文你传入的 Comparator 就是策略。你看策略模式在标准库里已经存在了几十年只是很多人没把它跟设计模式联系起来。类似的还有ThreadPoolExecutor的拒绝策略、Spring的资源加载器、MyBatis中各种Interceptor插件机制。如果你把这些例子对照阅读策略模式就不再是课本上的概念而是融入日常编码的本能。5.3 策略模式和高阶变体怎么搭配策略模式很少孤立使用它经常和其他几种模式组合出行遇到更复杂的业务场景就有用武之地了。策略模式 简单工厂解决策略选择的问题。上面写的PromotionStrategyFactory就是这种组合。简单工厂负责把创建和选择策略的职责集中起来外部只和工厂打交道因此调用方不需要知道具体策略类的名字。策略模式 模板方法解决多个策略有相同流程骨架的问题。比如导出报表每个策略都要执行“查询数据 - 填充模板 - 压缩 - 上传”这四步只有每步的细节不一样。把公共流程写在抽象模板类中让子类实现差异部分就能避免每个策略都重复写整套流程代码。策略模式 组合策略解决多个策略叠加执行的问题。真实业务存在满减和会员折扣同时生效的情况单一策略模式是替换关系没法直接叠加。我一般会写一个CompositeStrategy内部持有多个策略按照顺序依次执行上一个策略计算出的结果作为下一个策略的输入Component public class CompositeStrategy implements PromotionStrategy { private final ListPromotionStrategy strategies; Override public BigDecimal calculate(OrderInfo order) { BigDecimal price order.getTotalPrice(); for (PromotionStrategy strategy : strategies) { order.setTotalPrice(price); price strategy.calculate(order); } return price; } }组合策略的价值在于调用方依然只面对一个策略对象内部到底跑多少个规则完全被封装起来。这个变体我在营销系统中用得很多效果非常直接。6. 实战中遇过的坑和排查技巧6.1 Spring 注入 Map 的 key 不是预期值这个坑我踩过一次印象极深。第一版策略工厂我图省事直接用MapString, PromotionStrategy做注入Autowired private MapString, PromotionStrategy strategyMap;然后自信满满地通过strategyMap.get(FULL_REDUCTION)取策略结果返回 null。排查半天才发现Spring 注入 Map 时key 默认是 Bean 的名称而 Bean 默认名称是类名首字母小写也就是fullReductionStrategy。一个大写一个驼峰当然取不到。解决方案有两种一是给Component(FULL_REDUCTION)显式命名让 key 和约定一致二是不依赖默认 Bean 名的映射直接遍历 Map 的所有策略调用getType()判断类型。我后来坚定不移用第二种因为策略本身知道自己是哪种类型这样不依赖 Spring 内部的命名约定重构类名时也不怕策略解析静默失效。6.2 策略类爆炸以及如何止损策略模式用多了目录下的实现类越来越多。有一次优惠规则扩展到了 20 多种每个类就两三行算法看文件列表都费劲。这时就要反思是不是所有逻辑都适合拆独立策略类我的止损标准有两个。第一策略逻辑简单到只有两三行、也没有外部依赖可以用枚举 函数式接口把逻辑收纳进去。比如直接按你的Function配方存 lambda见 4.4 节。这种写法适合极小的规则但不适合复杂业务。第二策略类数量极其庞大且逻辑相似公共部分抽到抽象基类或模板方法中子类只实现差异部分减少重复代码。反过来也有一种情况多个策略逻辑差异太大硬塞进同一个类只会让类内部又堆满 if-else。越大的策略越需要独立成文件这是策略模式的优势不要怕类多怕的是类内部失控。6.3 策略里保存了请求维度的状态Spring 默认情况下把所有 Bean 都当成单例。应用启动后整个容器只有一个DiscountStrategy实例所有线程共享。如果你在这个策略类里加了一个成员变量用来保存本次计算的中间结果Component public class DiscountStrategy implements PromotionStrategy { private BigDecimal finalPrice; // 并发下会被多个请求互相污染 }那就完蛋了。多个请求同时进来成员变量会被反复覆盖后一个请求读到的可能是前一个请求留下的脏数据。策略类必须保持无状态所有计算过程的中间值放到方法局部变量里或者作为参数传来传去。如果某个策略确实需要绑定请求级数据也应该把数据放进OrderInfo对象里传给方法而不是存在策略自己的字段里。我在做订单优惠时还碰到过更隐蔽的问题策略内部调了用户服务但用户上下文是存在请求级变量里的。结果并发压测时A 用户的请求拿到了 B 用户的会员等级。改成从OrderInfo里取 userId再根据 userId 重新查询用户信息一切才正常。记住这个原则策略对象天然是单例共享的任何请求局部信息都不能放成员变量。6.4 金额计算别用 double这个坑几乎是所有涉及钱的项目都绕不开的。教学示例为了直观用double没问题但真实工程项目里优惠金额、订单金额、折扣结果一律用BigDecimal。原因大家都知道二进制浮点数无法精确表示 0.1用double计算金额会积累精度误差最后可能差一分钱。用BigDecimal还有一个细节构造时别传double字面量比如new BigDecimal(0.8)得到的对象会带着一长串尾数。正确做法是传字符串比如new BigDecimal(0.8)。我做代码评审时经常看到有人在这个细节上翻车顺手写进避坑清单。6.5 让策略自己决定是否能处理最后分享一个我后来非常喜欢的扩展思路给策略接口加一个默认的support方法让策略自己判断是否适用于当前请求。public interface PromotionStrategy { PromotionType getType(); default boolean support(OrderInfo order) { return false; } BigDecimal calculate(OrderInfo order); }具体策略按需重写supportComponent public class NewCustomerStrategy implements PromotionStrategy { Override public boolean support(OrderInfo order) { return order.isNewCustomer(); } Override public PromotionType getType() { return PromotionType.NEW_CUSTOMER; } Override public BigDecimal calculate(OrderInfo order) { // 新客立减 10 元 } }工厂遍历所有策略返回第一个满足条件的策略来执行。这样“根据类型选策略”的强映射进一步弱化策略的适用边界由策略自己表达。我在重构优惠系统时用了这套思路后来连续加了“新客专享”“渠道专享”“时间段限时”好几类新策略愣是没动过工厂和调用方一行代码。这种从“工厂替我选策略”到“策略自己认领任务”的演进是策略模式在真实业务里最漂亮的打开方式之一。我个人在实战中的体会是策略模式真正发挥作用的地方不在于代码写得多花哨而在于团队是否愿意在新需求到来时先想一想这个是不是又一个策略如果是就按扩展策略类的方式去加而不是把分支继续堆到老方法里。模式很多时候就是一道闸门拦住了代码腐化的路径。最后再分享一个小技巧如果你想让策略的选择逻辑完全自动化可以在接口里加一个support方法配合工厂遍历让每个策略自己“认领”能处理的场景这个方法我在多个项目里验证下来极其顺手推荐你下个项目直接试试。
说服力最强的永远是项目里的真实痛点。先别管策略模式的定义多高深想想你有没有写过这样一种 Java 代码一个方法里全是 if-else每加一种新玩法就要打开老方法再补一个分支补着补着方法变成几百行测试用例看着都眼晕。如果你点头了那你需要的就是策略模式。这篇文章面向小白但不会只停留在“什么是策略模式”我会从最原始的痛点场景讲起带你手写一个能运行的最小示例再给出真实项目里最常用的“枚举 Spring 容器”玩法最后把多态原理和实战中常见的坑一次说清楚。看完你就能在项目里落地而且心里明白为什么这么写是对的。1. 策略模式到底在解决什么问题1.1 一段让人头皮发麻的 if-else假设你在维护一个电商订单模块要计算商品优惠后的价格。最开始只有一种满减券代码很清爽public double calculateCouponPrice(Order order) { if (order.getTotalPrice() 100) { return order.getTotalPrice() - 20; } return order.getTotalPrice(); }后来业务扩张加了折扣券、无门槛立减、还有会员专属价。你会发现很多人的第一反应都是继续往同一个方法里堆分支public double calculateCouponPrice(Order order, Integer couponType) { double total order.getTotalPrice(); if (couponType 1) { if (total 100) { return total - 20; } return total; } else if (couponType 2) { return total * 0.8; } else if (couponType 3) { return total - 5; } return total; }问题在哪儿首先是“新增需求要动老代码”。下个月要加“第二件半价”你还是得打开calculateCouponPrice在最底下补一个 else if。改一个稳定的老方法本身就是风险一个不小心影响了满减逻辑线上订单就全算了错账。其次是“判断逻辑和执行逻辑绑在了一起”。这种方法里混杂着“这个单子适用哪种规则”和“这种规则具体怎么算”两件事职责不清晰而且随着分支增多可读性急剧下降。测试呢为了覆盖所有分支你得把每种类型都调用一遍分支的组合一多测试用例数量简直爆炸。这种坏味道在真实项目里非常常见包括后面说的支付方式、消息推送渠道、报表导出格式选择模式是一模一样的。它的本质是一系列算法规则被平铺到一个方法里每次新增算法都得修改既有代码。1.2 用快餐店点餐理解策略模式我们用一个生活化的场景把策略模式讲明白。想象一家快餐店柜台后的服务员脑子像一本厚厚的菜单手册。你说“我要 A 套餐”服务员就开始背A 套餐包含什么、价格多少、怎么打包。餐厅一旦推出 B 套餐、C 套餐服务员就得重新接受培训把新套餐的所有规则背下来。这个服务员对应的就是上面那个又长又乱的大方法所有套餐规则都集中在他的大脑里。现在换成自助点餐机。机器屏幕上有 A、B、C 套餐按钮你按 AA 套餐的程序逻辑自己负责计算价格和下单你按 BB 套餐的另一套程序接管。餐厅出新套餐时只需要在机器里增加一个新的套餐实现点餐机的主体流程、屏幕框架统统不用改动。策略模式就是这套点餐机逻辑的代码版。点餐机是“上下文”套餐按钮对应的逻辑是“具体策略”而“如何生成一单”的统一规则就是“策略接口”。它要解决的正是上面那段 if-else 的核心病根让算法各自成类调用方只依赖一个稳定接口不对具体实现指手画脚。这样新增算法不需要改动老代码这就是设计模式里常说的“开闭原则”的落地。2. 策略模式的三件套和原理2.1 三个角色分别是谁策略模式的角色比很多设计模式都要简洁核心就三个。策略接口Strategy定义一族算法的统一入口。比如“计算优惠后的价格”接口里定义一个方法BigDecimal calculate(OrderInfo order)。它不关心具体怎么算只约定实现类必须提供这个能力。策略接口的存在让调用方能够面向接口编程而不是依赖某一个具体类。具体策略ConcreteStrategy实现策略接口的各个类。满减类、折扣类、立减类各写各的算法彼此独立。新增一种规则就是新增一个实现类。这个方法最大的好处是隔离了变化每个策略的改动只会影响自己不会波及其他策略。上下文Context持有策略接口的引用对外提供统一的执行入口。它相当于点餐机的机器本体内部怎么运行外部不关心外部只知道把策略丢给它然后它可以计算出结果。上下文还可以承载公共逻辑比如参数校验、日志记录、埋点上报这样这些逻辑不会在每个具体策略里重复出现。用一个图意会一下它们的关系客户端创建上下文上下文持有接口引用引用指向某个具体策略调用方法时由具体策略执行算法。// 策略接口 public interface PriceStrategy { BigDecimal calculate(OrderInfo order); } // 具体策略满减 public class FullReductionStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { // 具体满减逻辑 return null; } } // 上下文 public class PriceContext { private PriceStrategy strategy; public PriceContext(PriceStrategy strategy) { this.strategy strategy; } public BigDecimal execute(OrderInfo order) { // 这个地方可以扩展公共逻辑比如日志、校验 return strategy.calculate(order); } }现在你心里应该有了一张粗略地图。接下来要回答一个更关键的问题这样设计凭什么能让代码更好维护2.2 开闭原则和多态才是底层逻辑策略模式不只是一个代码组织技巧它背后站着两个基础机制开闭原则和动态绑定。开闭原则的意思是对扩展开放对修改关闭。当你新增一种“新客立减 10 元”的优惠时按照策略模式的写法你只需要新写一个NewCustomerStrategy实现类然后让工厂或者客户端在需要的时候传进上下文。满减、折扣等已有策略类和上下文的核心流程全都纹丝不动。这就是“对修改关闭”——老代码零触碰风险因此被压到最低。动态绑定则是 Java 语言给策略模式提供的运行时引擎。你在代码里声明的类型是PriceStrategy但实际引用的对象可以是任意一个实现类。JVM 在运行时才会根据对象的真实类型决定调用哪个实现类的方法。正因为有这个机制上下文里的PriceStrategy strategy才能今天指向满减明天指向折扣而上下文自己不需要任何改动。如果你在非面向对象语言里写十几个策略实现类还得靠手动分发策略模式的优势就没这么明显了。还有一个隐藏的重要原则组合优先于继承。策略模式没有让上下文继承某一个具体策略而是通过接口变量持有策略对象这是一种“组合关系”。组合相比继承耦合更低、更灵活。继承是is-a策略模式里上下文和策略是has-a上下文“有一个”策略而不是“是一个”策略。理解了“组合优于继承”你才算真正看懂了策略模式的设计哲学。3. 从零手写一个最小可运行示例3.1 定义策略接口为什么推荐传对象前面理论说多了直接动手写一个能跑的最小示例。工程不需要任何框架JDK 8 以上即可一个接口、三个实现类、一个上下文、一个 main 方法。第一步定义订单信息对象。这里有个容易被新手忽略的好习惯策略接口的参数尽量传一个上下文对象而不是一堆散参。如果接口方法写成BigDecimal calculate(double price, int userLevel, String channel)以后策略需要新增一个“地区编码”参数接口签名要改所有实现类签名都要跟着改那策略模式的好处就被抵消一半。而传一个OrderInfo对象新增字段完全不影响接口public class OrderInfo { private BigDecimal totalPrice; private int userLevel; private String channel; // 构造器、getter/setter 省略 }第二步定义策略接口public interface PriceStrategy { BigDecimal calculate(OrderInfo order); }这里我直接用BigDecimal返回值。真实项目中涉及金额计算别用double这章末尾我也会单独列为禁忌。3.2 实现三种具体策略接下来写三个标准策略满减、折扣、无门槛立减。每个策略类只关心自己的算法不要互相依赖。public class FullReductionStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { BigDecimal total order.getTotalPrice(); // 满 100 减 20 if (total.compareTo(new BigDecimal(100)) 0) { return total.subtract(new BigDecimal(20)); } return total; } }public class DiscountStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { // 打 8 折 return order.getTotalPrice().multiply(new BigDecimal(0.8)); } }public class CashOffStrategy implements PriceStrategy { Override public BigDecimal calculate(OrderInfo order) { BigDecimal result order.getTotalPrice().subtract(new BigDecimal(5)); // 最低不能低于 0 if (result.compareTo(BigDecimal.ZERO) 0) { return BigDecimal.ZERO; } return result; } }写这几个类时有几个细节值得强调。第一满减策略里的阈值和减额我用了字符串构造BigDecimal(100)而不是new BigDecimal(100)也不建议用new BigDecimal(0.8)这种浮点字面量否则会出现无法精确表示的尾数第二每个策略内部逻辑是完全自洽的满减策略里绝不能出现“如果用户是会员走折扣”这种跳转到其他策略的逻辑策略之间必须保持独立否则就破坏了可替换性。3.3 用上下文串起来并测试上下文类负责持有策略引用并且可以在这里加一些所有策略都会用到的公共处理。public class PriceContext { private PriceStrategy strategy; public PriceContext(PriceStrategy strategy) { this.strategy strategy; } public BigDecimal execute(OrderInfo order) { // 公共校验逻辑可以写在这里 return strategy.calculate(order); } }这里我用构造器传入策略而不是暴露 setter 方法。两者的区别我在实际项目中体会很深构造器注入适合一次上下文对应一次策略计算策略相对固定setter 注入则适合同一个上下文在不同阶段切换策略。但要注意如果你用 Spring 管理上下文并且上下文是单例那么成员变量存策略就必须小心因为单例会被多个线程共享策略如果带有请求级状态很容易出并发问题这在我们第六章的避坑部分会展开说。客户端调用public class StrategyDemo { public static void main(String[] args) { OrderInfo order new OrderInfo(); order.setTotalPrice(new BigDecimal(120)); PriceContext context new PriceContext(new FullReductionStrategy()); System.out.println(满减价格: context.execute(order)); context new PriceContext(new DiscountStrategy()); System.out.println(折扣价格: context.execute(order)); context new PriceContext(new CashOffStrategy()); System.out.println(立减价格: context.execute(order)); } }输出分别是 100、96、115和手算一致。现在你亲手跑通了一个完整的策略模式示例。不过别急着开心这个示例里藏着两个问题真实项目里必须解决第一客户端在创建PriceContext时还是在用new FullReductionStrategy()这种方式来选策略等于把 if-else 从算法内部搬到了客户端问题并没有根除第二策略对象都是手动 new 的没有交给 Spring 管理这样策略类里想注入其他依赖就非常麻烦。下一章我们来看工程化的标准解法。4. 真实项目玩法策略模式 枚举 Spring 容器4.1 原生策略模式在项目里的尴尬手动 new 策略的写法在教学示例里没毛病但拿到真实项目里就会碰到两个尴尬处境。第一个尴尬是“选策略的 if-else 依然存在”。用户下单的时候要根据优惠券类型选择执行哪个策略代码大概率长成这样PriceStrategy strategy; if (FULL_REDUCTION.equals(couponType)) { strategy new FullReductionStrategy(); } else if (DISCOUNT.equals(couponType)) { strategy new DiscountStrategy(); } else if (CASH_OFF.equals(couponType)) { strategy new CashOffStrategy(); }写到这里很多人会恍然大悟这不就是换了种写法的 if-else 吗原来的是规则判断现在的是策略选择判断。本质上分支没有被消灭只是挪了个位置。第二个尴尬是 Spring 管理。手动 new 出来的策略不在 Spring 容器里Autowired注入其他服务一概失效。而真实业务里折扣策略可能需要调用户积分服务、风控策略可能需要查黑名单、满减策略可能要读配置中心的阈值。没有容器这些依赖全部无法注入。真正的解法是让 Spring 容器把所有PriceStrategy的实现类自动收集成一个 Map 或 List然后用策略类型去拿对应的策略 Bean。Spring 对接口集合注入有天然支持用起来非常顺手。4.2 用枚举统一管理策略标识要优雅地标识策略优先用枚举而不是魔法字符串。枚举的好处是编译期检查写错类型名编译直接报错而不是运行到那行才发现取了个 null而且枚举天然适合做 switch 和 Map 的 key。public enum PromotionType { FULL_REDUCTION(满减), DISCOUNT(折扣), CASH_OFF(立减); private final String desc; PromotionType(String desc) { this.desc desc; } }接着定义策略接口。为了让策略对象能自报家门我加了一个getType()方法每个实现类返回自己对应的枚举类型。这样做的好处后面会体现工厂不需要依赖 Spring 的 Bean 命名规则而是直接问策略对象“你是什么类型”语义非常清晰。public interface PromotionStrategy { PromotionType getType(); BigDecimal calculate(OrderInfo order); }三个实现类分别加上Component让 Spring 扫描到它们Component public class FullReductionStrategy implements PromotionStrategy { Override public PromotionType getType() { return PromotionType.FULL_REDUCTION; } Override public BigDecimal calculate(OrderInfo order) { // 满减实现 } }DiscountStrategy和CashOffStrategy结构类似不重复贴代码。4.3 用 Spring 自动收集策略 Bean这是整篇文章里最有工程价值的一部分。在 Spring 中你可以直接把一个接口的多个实现类注入到MapString, PromotionStrategy或ListPromotionStrategy中。Spring 会扫描容器内所有该接口的实现 Bean自动填充集合。我们写一个策略工厂Component public class PromotionStrategyFactory { private final ListPromotionStrategy strategyList; Autowired public PromotionStrategyFactory(ListPromotionStrategy strategyList) { this.strategyList strategyList; } public PromotionStrategy getStrategy(PromotionType type) { return strategyList.stream() .filter(strategy - strategy.getType() type) .findFirst() .orElseThrow(() - new IllegalArgumentException(未找到对应的策略: type)); } }细看这段代码工厂内部没有冗余的分支判断而是遍历所有策略通过getType() type找到匹配项。这种写法的扩展性极强以后新增一种优惠只需要新写一个实现类实现PromotionType对应方法然后再在枚举中加一个值。策略工厂一行都不用改调用方一行都不用改。真正做到了“开闭原则”。初学者容易困惑的一个点为什么这里选择注入List而不是MapString, PromotionStrategy如果我注入 Mapkey 是 Bean 的名称类名的默认小驼峰跟枚举名完全不搭还需要额外处理大小写和命名规则。而注入 List 加上getType()方法策略类型信息完全由类自身表达不会因为重构类名或改变 Bean 命名约定而出问题。这是我在项目里迭代之后沉淀下来的经验。4.4 调用方可以干净到什么程度有工厂之后业务代码会简洁到几乎看不出策略的存在。比如订单结算服务Service public class OrderService { private final PromotionStrategyFactory promotionStrategyFactory; Autowired public OrderService(PromotionStrategyFactory promotionStrategyFactory) { this.promotionStrategyFactory promotionStrategyFactory; } public BigDecimal checkout(OrderInfo order, PromotionType promotionType) { PromotionStrategy strategy promotionStrategyFactory.getStrategy(promotionType); return strategy.calculate(order); } }如果后面要做叠加促销你甚至可以写一个 CompositeStrategy内部包一个ListPromotionStrategy循环执行把上一个策略的结果传给下一个。这个变体我们在第五章讲它属于策略模式的扩展玩法不是核心但很常用。如果你觉得为了两行计算逻辑就建一个类文件很浪费还有一个轻量级方案用枚举持有函数式接口。比如在PromotionType枚举里加一个FunctionOrderInfo, BigDecimal calculator字段每个枚举值对应一段 lambda。这样确实能减少类数量代码也紧凑。但是注意一旦策略逻辑超过三行或者需要复用其他 Spring 服务就别硬塞进枚举否则一个隐藏在大段 lambda 里的复杂逻辑反而难以测试和维护。什么时候用独立策略类什么时候用轻量枚举我的判断标准是策略内部是否依赖其他业务服务逻辑是否超过三行。5. 深入原理多态、动态绑定与变体5.1 从多态理解策略模式的运行时行为策略模式为什么能运行时切换算法这个能力完全来自 Java 的动态绑定机制。在你写PromotionStrategy strategy这个引用时编译器的静态类型是接口编译器只会安全地允许你调用PromotionStrategy接口里定义的方法。程序真正运行的时候JVM 会查看这个引用实际指向的对象类型再找到该对象所属类的方法表调用对应实现。这就是“动态绑定”方法调用的目标不是编译期决定的而是运行期决定的。举个具体例子工厂返回一个FullReductionStrategy对象但方法的声明返回类型是PromotionStrategy编译器不知道它的真实类型运行时 JVM 却知道所以执行的是满减的calculate。换一个DiscountStrategy对象同样的代码执行的就是折扣的calculate。策略模式正是充分利用了这个语言特性才做到上下文代码零改动。这里我也想提醒一个容易踩的设计细节策略接口的方法签名一定要尽量稳定。如果方法签名里写死BigDecimal calculate(BigDecimal price, String channel)以后策略需要用户等级、订单明细、地区信息接口就要改所有策略实现类都要同步改。改成传一个上下文对象后接口自身非常稳定新需求只要往上下文里加字段。我见过好几个人因为参数问题反复改策略接口最后抱怨策略模式不好用其实问题出在接口设计上。5.2 标准库里到处都是策略模式学设计模式最有效的辅助方式之一就是在标准库里找现成的例子。Java 标准库最典型的就是java.util.Comparator。Comparator就是经典的策略接口它的compare方法是算法入口。同一组对象排序时你可以传入不同的 Comparator 实现实现按年龄排、按姓名排、按金额排。Collections.sort算法本身完全不关心具体排序规则它只是调用你传入的策略。排序方法相当于上下文你传入的 Comparator 就是策略。你看策略模式在标准库里已经存在了几十年只是很多人没把它跟设计模式联系起来。类似的还有ThreadPoolExecutor的拒绝策略、Spring的资源加载器、MyBatis中各种Interceptor插件机制。如果你把这些例子对照阅读策略模式就不再是课本上的概念而是融入日常编码的本能。5.3 策略模式和高阶变体怎么搭配策略模式很少孤立使用它经常和其他几种模式组合出行遇到更复杂的业务场景就有用武之地了。策略模式 简单工厂解决策略选择的问题。上面写的PromotionStrategyFactory就是这种组合。简单工厂负责把创建和选择策略的职责集中起来外部只和工厂打交道因此调用方不需要知道具体策略类的名字。策略模式 模板方法解决多个策略有相同流程骨架的问题。比如导出报表每个策略都要执行“查询数据 - 填充模板 - 压缩 - 上传”这四步只有每步的细节不一样。把公共流程写在抽象模板类中让子类实现差异部分就能避免每个策略都重复写整套流程代码。策略模式 组合策略解决多个策略叠加执行的问题。真实业务存在满减和会员折扣同时生效的情况单一策略模式是替换关系没法直接叠加。我一般会写一个CompositeStrategy内部持有多个策略按照顺序依次执行上一个策略计算出的结果作为下一个策略的输入Component public class CompositeStrategy implements PromotionStrategy { private final ListPromotionStrategy strategies; Override public BigDecimal calculate(OrderInfo order) { BigDecimal price order.getTotalPrice(); for (PromotionStrategy strategy : strategies) { order.setTotalPrice(price); price strategy.calculate(order); } return price; } }组合策略的价值在于调用方依然只面对一个策略对象内部到底跑多少个规则完全被封装起来。这个变体我在营销系统中用得很多效果非常直接。6. 实战中遇过的坑和排查技巧6.1 Spring 注入 Map 的 key 不是预期值这个坑我踩过一次印象极深。第一版策略工厂我图省事直接用MapString, PromotionStrategy做注入Autowired private MapString, PromotionStrategy strategyMap;然后自信满满地通过strategyMap.get(FULL_REDUCTION)取策略结果返回 null。排查半天才发现Spring 注入 Map 时key 默认是 Bean 的名称而 Bean 默认名称是类名首字母小写也就是fullReductionStrategy。一个大写一个驼峰当然取不到。解决方案有两种一是给Component(FULL_REDUCTION)显式命名让 key 和约定一致二是不依赖默认 Bean 名的映射直接遍历 Map 的所有策略调用getType()判断类型。我后来坚定不移用第二种因为策略本身知道自己是哪种类型这样不依赖 Spring 内部的命名约定重构类名时也不怕策略解析静默失效。6.2 策略类爆炸以及如何止损策略模式用多了目录下的实现类越来越多。有一次优惠规则扩展到了 20 多种每个类就两三行算法看文件列表都费劲。这时就要反思是不是所有逻辑都适合拆独立策略类我的止损标准有两个。第一策略逻辑简单到只有两三行、也没有外部依赖可以用枚举 函数式接口把逻辑收纳进去。比如直接按你的Function配方存 lambda见 4.4 节。这种写法适合极小的规则但不适合复杂业务。第二策略类数量极其庞大且逻辑相似公共部分抽到抽象基类或模板方法中子类只实现差异部分减少重复代码。反过来也有一种情况多个策略逻辑差异太大硬塞进同一个类只会让类内部又堆满 if-else。越大的策略越需要独立成文件这是策略模式的优势不要怕类多怕的是类内部失控。6.3 策略里保存了请求维度的状态Spring 默认情况下把所有 Bean 都当成单例。应用启动后整个容器只有一个DiscountStrategy实例所有线程共享。如果你在这个策略类里加了一个成员变量用来保存本次计算的中间结果Component public class DiscountStrategy implements PromotionStrategy { private BigDecimal finalPrice; // 并发下会被多个请求互相污染 }那就完蛋了。多个请求同时进来成员变量会被反复覆盖后一个请求读到的可能是前一个请求留下的脏数据。策略类必须保持无状态所有计算过程的中间值放到方法局部变量里或者作为参数传来传去。如果某个策略确实需要绑定请求级数据也应该把数据放进OrderInfo对象里传给方法而不是存在策略自己的字段里。我在做订单优惠时还碰到过更隐蔽的问题策略内部调了用户服务但用户上下文是存在请求级变量里的。结果并发压测时A 用户的请求拿到了 B 用户的会员等级。改成从OrderInfo里取 userId再根据 userId 重新查询用户信息一切才正常。记住这个原则策略对象天然是单例共享的任何请求局部信息都不能放成员变量。6.4 金额计算别用 double这个坑几乎是所有涉及钱的项目都绕不开的。教学示例为了直观用double没问题但真实工程项目里优惠金额、订单金额、折扣结果一律用BigDecimal。原因大家都知道二进制浮点数无法精确表示 0.1用double计算金额会积累精度误差最后可能差一分钱。用BigDecimal还有一个细节构造时别传double字面量比如new BigDecimal(0.8)得到的对象会带着一长串尾数。正确做法是传字符串比如new BigDecimal(0.8)。我做代码评审时经常看到有人在这个细节上翻车顺手写进避坑清单。6.5 让策略自己决定是否能处理最后分享一个我后来非常喜欢的扩展思路给策略接口加一个默认的support方法让策略自己判断是否适用于当前请求。public interface PromotionStrategy { PromotionType getType(); default boolean support(OrderInfo order) { return false; } BigDecimal calculate(OrderInfo order); }具体策略按需重写supportComponent public class NewCustomerStrategy implements PromotionStrategy { Override public boolean support(OrderInfo order) { return order.isNewCustomer(); } Override public PromotionType getType() { return PromotionType.NEW_CUSTOMER; } Override public BigDecimal calculate(OrderInfo order) { // 新客立减 10 元 } }工厂遍历所有策略返回第一个满足条件的策略来执行。这样“根据类型选策略”的强映射进一步弱化策略的适用边界由策略自己表达。我在重构优惠系统时用了这套思路后来连续加了“新客专享”“渠道专享”“时间段限时”好几类新策略愣是没动过工厂和调用方一行代码。这种从“工厂替我选策略”到“策略自己认领任务”的演进是策略模式在真实业务里最漂亮的打开方式之一。我个人在实战中的体会是策略模式真正发挥作用的地方不在于代码写得多花哨而在于团队是否愿意在新需求到来时先想一想这个是不是又一个策略如果是就按扩展策略类的方式去加而不是把分支继续堆到老方法里。模式很多时候就是一道闸门拦住了代码腐化的路径。最后再分享一个小技巧如果你想让策略的选择逻辑完全自动化可以在接口里加一个support方法配合工厂遍历让每个策略自己“认领”能处理的场景这个方法我在多个项目里验证下来极其顺手推荐你下个项目直接试试。
