策略模式是结合条件控制流与面向对象设计的核心方法：通过统一接口封装不同行为，将条件判断前置到对象创建环节，用工厂模式隐藏复杂逻辑，借助组合与异常封装提升可维护性与扩展性。
条件控制流是程序执行路径的“开关”，面向对象设计原则是代码结构的“骨架”。把二者自然结合，不是简单地在 if 里 new 一个对象，而是让判断逻辑服务于职责划分、让对象行为响应条件变化、让扩展不依赖修改。
用策略模式替代硬编码分支
当一段 if-else 或 switch 处理多种业务规则（比如不同支付方式、不同折扣类型），直接写死会违反开闭原则。应提取共性接口，将每种分支封装为独立策略类。
- 定义统一接口：PaymentStrategy 含 process() 方法
- 每个具体实现类（WechatPayStrategy、AlipayStrategy）只专注自身逻辑
- 主流程中根据参数选择对应策略实例，调用统一方法 —— 条件判断只出现在创建策略这一步，后续完全解耦
让条件决定对象构造，而非运行时行为切换
避免在对象方法内部堆砌大量 if 判断来区分状态或类型。应把条件前置到对象创建环节，让不同对象天然具备不同行为。
- 例如订单状态处理：不写 if (status == PAID) { ... } else if (status == CANCELLED) { ... }
- 改为按状态构造不同子类对象（PaidOrder、CancelledOrder），各自重写 handle() 方法
- 这样既体现多态，又使每个类职责单一，新增状态只需加新类，不改旧代码
用工厂+组合隐藏条件复杂度
当对象初始化需要依据多个条件组合（如地区、用户等级、设备类型）生成不同配置，工厂类可集中处理判断逻辑，并返回已组装好的对象。
- 工厂内部用嵌套 if 或查表方式解析条件，但对外只暴露一个创建方法
- 返回的对象本身不暴露判断痕迹，而是通过组合其他组件（如 PriceCalculator、NotificationService）体现差异
- 后续想替换某类计算逻辑，只需换掉被组合的组件，不影响工厂和主对象结构
异常与条件协同体现封装边界
条件判断常伴随异常抛出（如参数校验失败、资源不可用）。把这些检查逻辑封装进对象构造或 setter 中，比散落在各处的 if + throw 更利于维护。
- 例如 User 类的构造器中校验邮箱格式，不合法直接抛 IllegalArgumentException
- 调用方无需重复写校验代码，也避免因遗漏判断导致后续空指针或逻辑错乱
- 若校验规则变化（如增加手机号验证），只需改 User 类，不波及所有使用点
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
