17370845950

策略模式适用于运行时动态切换算法或业务规则的场景，通过统一接口封装多种实现（如支付方式、排序算法），避免if-else冗余，支持配置驱动、灵活扩展与统一监控。

策略模式适合需要在运行时动态切换算法、行为或业务规则的场景，尤其当这些行为有多种实现且可能频繁增减时。

存在多个相似但不同的算法实现

比如支付方式（微信支付、支付宝、银行卡）、排序算法（快速排序、归并排序、冒泡排序）、日志输出格式（JSON、XML、纯文本）。这些实现逻辑不同，但对外接口一致。用策略模式可以把每种算法封装成独立类，避免大量if-else或switch分支，也便于单独测试和复用。

• 定义统一策略接口（如PaymentStrategy）
• 每个具体策略实现该接口（WechatPayStrategy、AlipayStrategy）
• 上下文类（如OrderService）持有一个策略引用，运行时注入

业务规则经常变化或需要外部配置驱动

例如风控系统中，不同用户等级适用不同审核策略（白名单跳过、基础校验、人工复核）；又如促销引擎中，满减、折扣、赠品等规则需按活动动态加载。策略模式配合工厂或配置中心（如Spring Profile、Nacos配置），可做到不改代码切换规则。

• 策略实现类可标注注解（如@Strategy("vip_review")）
• 通过策略名从Spring容器或Map中获取对应实例
• 配置变更后，只需更新配置项，无需重新部署

避免继承体系过度膨胀

当用继承来表达行为差异（如ReportGenerator派生出PdfReportGenerator、ExcelReportGenerator、HtmlReportGenerator），会导致子类数量激增，且难以组合扩展（比如既要PDF又要带水印）。策略模式将行为剥离为组合关系，更灵活。

• 主类（如ReportService）聚合一个ReportStrategy
• 水印功能可作为装饰策略（WatermarkedPdfStrategy）包装原始策略
• 新增格式或增强行为，不影响原有类结构

需要对算法做统一管理或监控

比如统计各策略调用次数、耗时、成功率，或统一加事务、重试、熔断。策略模式天然支持在上下文或代理层统一拦截，而不用在每个算法内部重复写监控逻辑。

• 用AOP切面环绕所有策略执行方法
• 策略上下文可记录执行上下文（traceId、用户ID）供排查
• 策略接口可扩展getStrategyCode()、getVersion()等元信息

策略模式不是为了解耦而解耦，核心是把“变”的部分隔离出来，让主流程稳定、可测、易维护。用错场景（比如只有一种策略、策略间完全无关、策略状态严重耦合）反而增加复杂度。