多态通过策略模式+工厂将类型选择上移到对象创建处，调用方只面对统一接口；枚举+抽象方法适合固定分支场景；模板方法固化共性流程；但参数校验等非类型分支应保留if。
多态是面向对象的核心特性之一，它能有效解耦逻辑判断与具体行为，把运行时才确定的分支选择交给子类实现，从而替代大量硬编码的 if-else 或 switch。关键不在于“去掉条件”，而在于“把条件判断上移到创建对象的地方”，让调用方只面对统一接口，不关心具体类型。
用策略模式 + 工厂封装类型选择
将不同业务场景抽象为策略接口，每个实现类专注一种行为；再通过简单工厂或 Spring 的 Bean 名称/注解驱动方式，根据输入参数（如订单类型、支付方式、状态码）返回对应策略实例。这样 if-else 只出现在工厂内部——且仅一处，后续所有调用都干净无分支。
- 定义统一接口：PaymentProcessor，含 process() 方法
- 实现多个子类：AlipayProcessor、WechatProcessor、BankTransferProcessor
- 工厂类根据 paymentType 字符串返回对应实例，调用方只需 processor.process()
利用枚举 + 抽象方法实现类型内聚
当分支数量固定、变化少（如订单状态：CREATED、PAID、SHIPPED、COMPLETED），可定义枚举，并在枚举中为每个常量实现抽象方法。枚举实例天然单例，无需 new，也不依赖 Spring 容器，适合轻量级策略场景。
- 声明 enum OrderStatus，含抽象方法 handle(Order order)
- 每个枚举项（如 PAID）直接提供该状态下的处理逻辑
- 调用时 status.handle(order)，完全避开 if 判断
配合模板方法模式固化流程结构
若不同子类逻辑有共性步骤（如“校验→执行→记录→通知”），可在抽象父类中定义模板方法，把可变部分声明为 protected abstract 方法，由子类实现。这样主干流程清晰，扩展只需新增子类，不改原有代码，符合开闭原则。
立即学习“Java免费学习笔记（深入）”；
- 抽象类 BaseOrderService 定义 execute() 模板方法
- 子类 PromotionOrderService 和 NormalOrderService 各自重写 doValidate() 和 doExecute()
- 新增一种订单类型？加个新子类即可，主流程零修改
注意边界：不是所有 if 都该被消灭
多态替代 if-else 适用于“同一语义、不同实现”的场景，比如支付方式、审批规则、消息格式化。但像参数校验（null 检查）、状态守卫（if (isClosed) throw）、简单布尔开关等，强行套用多态反而增加理解成本和对象开销。设计目标是提升可维护性，不是追求语法上的“无 if”。
- 条件分支基于类型或角色差异 → 适合多态
- 条件分支基于数据值、临时状态或防御性检查 → 保留 if 更自然
- 分支逻辑高度耦合、复用率低 → 先重构逻辑，再考虑是否抽象
