策略模式核心是分离判断与执行，将可变业务行为封装为独立策略，通过语义化接口、上下文参数、无状态实现及自动注册机制实现高内聚低耦合。

策略模式不是为了“消灭 if-else”而存在，而是把分散在业务主流程里的条件判断逻辑，转移到更合理的位置——让判断归判断，执行归执行，各司其职。

识别真正可变的业务行为

先别写代码，盯住原有 if-else 块：每个分支里真正不同的是什么？是发短信、邮件还是站内信？是按 VIP、黄金、白银算折扣？还是根据订单金额走不同风控规则？只要行为语义明确、未来可能新增或调整，就值得单独封装成策略。

• 避免拿枚举值（如 type == 1）直接映射策略，重点看“做什么”，而不是“叫什么数字”
• 如果某个分支内部还嵌套 if-else，说明它还没拆干净，需要再下沉一层
• 剥离公共逻辑（如日志、参数校验、异常包装），只保留该分支独有的核心动作

定义稳定、语义清晰的策略接口

接口方法名要体现业务意图，比如 applyDiscount()、notifyUser()，而不是笼统的 execute()。参数统一用上下文对象（如 OrderContext、NotificationContext），不塞原始类型或 Map 键值对。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 接口只声明契约，不暴露判断依据（例如不要定义 handle(String channel, BigDecimal amount)）
• 策略类保持无状态，不依赖外部变量；有状态逻辑应按需创建，而非复用单例
• 实现类命名带业务含义，如 SmsNotificationStrategy、SummerPromotionStrategy

用注册表或工厂解耦选择逻辑

别在调用处写一堆 if-else new 策略，也别用反射根据字符串加载类——调试难、IDE 跳转失效、编译期无检查。

• 推荐 Spring 场景下用 @Service + getBeansOfType() 扫描所有策略实现，启动时自动注册
• 搭配 canHandle(Context) 方法，由策略自己决定是否响应，上层只需遍历匹配
• 或者用枚举驱动：枚举字段直接关联策略类，通过 type.getStrategy().handle(context) 获取并执行

保留必要的守卫逻辑

入口处的非空校验、状态合法性检查、权限判断等，不属于策略范畴，留在调用方更清晰。策略模式不追求“零 if”，而是让 if 出现在该出现的地方——比如策略内部做金额阈值判断，或注册表里找匹配项。

• 主流程里只剩一行：strategy.handle(context)，没有分支，没有 switch
• 新增一种行为，只需加一个实现类 + 注解，不用改任何已有代码
• 单元测试可针对单个策略独立覆盖，不再需要为所有分支组合写 case