Java策略模式核心是接口定义行为契约、实现类封装具体算法、上下文动态切换策略：接口声明统一方法（如DiscountStrategy），实现类独立提供算法（如FixedDiscountStrategy），Context持接口引用解耦调用，配合工厂或配置管理策略选取。
Java 中用接口实现策略模式，核心是把算法的定义和使用分开：接口声明行为，不同实现类提供具体算法，调用方只依赖接口，不关心具体怎么算。
定义策略接口
用 interface 声明统一的行为契约，比如计算折扣、排序、支付方式等。接口方法不写实现，只规定“做什么”，不规定“怎么做”。
- 接口名建议体现策略意图，如 DiscountStrategy、SortStrategy
- 方法参数和返回值要通用，避免绑定具体业务对象（可借助泛型提升复用性）
- 不加默认方法（除非是辅助逻辑），保持纯抽象，让实现类完全掌控行为
编写多个策略实现类
每个类实现同一接口，封装一种独立算法。它们彼此无关，可单独测试、替换或扩展。
- 例如 FixedDiscountStrategy 返回固定金额减免，PercentageDiscountStrategy 按比例计算
- 实现类之间不要继承或强耦合，避免引入额外依赖
- 策略内部可持有配置参数（如折扣率），通过构造函数注入，增强灵活性
在上下文中组合并切换策略
创建一个“环境类”（Context），持有一个策略接口引用，运行时动态设置或更换策略实例。
立即学习“Java免费学习笔记（深入）”；
- Context 构造时可接收策略，或提供 setStrategy() 方法支持运行时切换
- 业务方法中只调用接口方法，如 strategy.apply(price)，完全解耦具体实现
- 结合工厂或 Spring Bean 管理策略实例，避免 new 多个实现类硬编码
实际调用时按需选择策略
调用方根据条件（如用户等级、订单金额、配置开关）决定用哪个策略，只需 new 或获取对应实现，传给 Context 即可。
- 避免在业务逻辑里写 if-else 判断后直接 new 具体类——那只是“伪策略”，没真正解耦
- 推荐用简单工厂、枚举映射或配置驱动（如读取 properties/yml）来集中管理策略选取逻辑
- 单元测试时可轻松 mock 策略接口，验证 Context 行为是否符合预期
不复杂但容易忽略：策略接口的粒度要合适——太粗（如一个 doWork()）难复用，太细（一堆小方法）增加维护成本。聚焦单一可变行为，一次只封装一类变化点。
