策略模式简化：switch分支与算法提取技巧

本文深入剖析了策略模式如何优雅替代难以维护的switch分支与if-else逻辑，从根源上解决硬编码、违反开闭原则和可读性差等痛点；通过清晰界定Strategy接口契约、规避状态泄漏风险、用枚举或Class替代字符串标识实现类型安全调度，并强调策略类必须严格遵循单一职责、杜绝反向调用，为构建高内聚、易扩展、可测试的业务算法体系提供了扎实可靠的最佳实践指南。

为什么 switch 分支难维护，而策略模式能解决它

因为 switch 把所有分支逻辑硬编码在一个方法里，每次新增类型就得改这个方法，违反开闭原则；同时类型判断和业务逻辑混在一起，可读性差、测试困难。策略模式把“选哪个算法”和“算法怎么实现”拆开，让每种行为独立成类，新增类型只需加一个实现类 + 注册，原调用处完全不动。

Strategy 接口定义要满足什么条件才好扩展

接口必须只暴露行为契约，不暴露实现细节或状态依赖。常见错误是把入参设计得太具体（比如塞进整个 Order 对象），导致策略类被迫处理无关字段；或者返回值类型太泛（如 Object），下游还得强转。

• 参数尽量精简：只传策略真正需要的数据，例如 calculateDiscount(double amount, String userType)
• 返回值明确：用具体类型（BigDecimal、Result）而非 Object 或 void
• 避免在接口中定义生命周期方法（如 init()、destroy()），那是上下文或框架该管的事

StrategyFactory 缓存策略对象时要注意状态泄漏

如果策略类里有成员变量（比如缓存计数器、临时上下文引用），直接用 static Map 缓存单例会导致并发问题或脏状态复用。无状态策略可以安全共享，但有状态的必须每次新建。

• 无状态策略：构造函数空、所有方法仅依赖入参，可预实例化并缓存到 Map
• 有状态策略：含 private int retryCount 或 private ThreadLocal 等，工厂中必须用 new ConcreteStrategyX() 每次创建
• Spring 场景下，推荐用 @Scope("prototype") 配合 @Qualifier 注解注入，比手写工厂更可控

如何让客户端代码彻底摆脱 if-else 和 type 字符串硬编码

核心是把类型标识从字符串升级为编译期可检查的契约。直接用 "A"、"B" 作 key，容易拼错且 IDE 不提示；换成枚举或策略类 Class 对象，就能利用类型系统兜底。

• 用枚举替代字符串：定义 enum PayType { ALIPAY, WECHAT, BANK }，工厂接收 PayType 而非 String
• 用 Class 作 key：注册时用 strategies.put(AlipayStrategy.class, new AlipayStrategy())，调用时传 AlipayStrategy.class，零字符串风险
• Spring Boot 中可结合 @ConditionalOnProperty 或配置中心动态启用/禁用某策略，但注册入口仍需静态明确

真实项目里最容易被忽略的是策略类的边界——它应该只做一件事，且不反向调用上下文或 Service 层。一旦出现 strategy.doX() → service.updateY() → strategy.doZ() 这种循环依赖，就说明职责没切干净，后续加日志、事务、重试都会变得异常脆弱。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《策略模式简化：switch分支与算法提取技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。