策略模式封装不同行为算法，工厂模式根据类型创建对应策略实例，二者结合将条件判断收拢至工厂，主流程仅执行策略，提升可扩展性与可维护性。
当代码中出现大量 if-else 或 switch-case 判断，尤其是根据类型、状态或行为分支执行不同逻辑时，维护和扩展都会变得困难。策略模式与工厂模式结合使用，能有效解耦条件判断与具体行为，提升代码的可读性与可扩展性。
策略模式：封装变化的行为
策略模式将每一种算法或行为封装成独立的类，使它们可以互相替换。通过统一接口调用不同实现，避免在主流程中写死逻辑。
例如，一个订单折扣计算功能，根据用户类型（普通、VIP、SVIP）采用不同计算方式：
- 定义策略接口：DiscountStrategy，包含 calculate(amount)
- 实现具体策略类：NormalDiscount、VIPDiscount、SVIPDiscount
- 上下文类 OrderProcessor 接收策略实例并执行计算
这样，新增折扣类型无需修改原有判断逻辑，只需添加新策略类并接入即可。
工厂模式：解耦对象创建
虽然策略模式分离了行为，但选择哪个策略仍可能依赖条件判断。工厂模式负责根据输入（如用户类型）创建对应的策略实例，把“选哪个”从主流程中剥离。
- 创建 DiscountStrategyFactory
- 工厂内部包含映射关系，如 { "normal": NormalDiscount, "vip": VIPDiscount }
- 对外提供 getStrategy(userType) 方法，返回对应策略实例
调用方只需传入类型，拿到策略对象，无需知道创建细节，也不接触 if-else 分支。
组合使用：清晰分工，易于维护
实际调用流程如下：
- 接收用户类型 userType
- 调用 factory.getStrategy(userType) 获取策略对象
- orderProcessor.setStrategy(strategy)
- processor.calculate(totalAmount)
if-else 判断被收拢到工厂内部，甚至可以用配置或映射表替代，后期扩展只需注册新策略，不改动核心逻辑。
优势与适用场景
这种组合特别适合：
- 多分支业务规则，如支付方式、审批流程、消息通知渠道
- 行为随类型或状态变化，且未来可能增加新类型
- 需要单元测试不同策略，隔离验证
基本上就这些。关键是把“做什么”（策略）和“怎么选”（工厂）分开，主流程只关心“执行”，结构更清晰，也更容易应对变化。
