多态使工厂类专注创建对象，调用方无需类型判断；工厂必须返回接口，JVM运行时自动绑定子类方法；分支逻辑集中于工厂内部，可用Spring注入、Map预加载或枚举实现；工厂方法模式支持新增类型不改旧代码，多态延伸至工厂本身。
多态本身不简化工厂类的逻辑，而是让工厂类的逻辑“只做一件事”：创建对象。真正简化的是使用方的代码——它不再需要判断类型、转换引用、写一堆 if-else，只需面向接口调用方法。工厂类内部可能仍有判断（比如用 if 或 Map 查找），但这个判断被严格限制在一处，其余所有地方都享受无分支调用。
工厂返回接口，调用方彻底免判断
工厂方法必须返回抽象类型（接口或抽象类），不能返回具体实现类。例如：
- ✅ 正确：
PaymentProcessor processor = factory.create("alipay"); processor.pay(amount); - ❌ 错误：
AlipayProcessor p = (AlipayProcessor) factory.create("alipay");—— 强转+类型依赖，多态失效
只要返回的是接口，JVM 就会在运行时自动绑定到实际子类的方法。业务代码里看不到任何 instanceof、switch 或字符串比对。
把分支逻辑收拢到工厂内部，且只留一种形式
工厂类是判断逻辑的唯一出口，但它的写法可以很轻量：
立即学习“Java免费学习笔记（深入）”；
- Spring 环境下，用
@Qualifier或 Bean 名称注入，连 if 都不用写 —— 容器根据配置自动装配对应实现 - 非 Spring 场景，用静态 Map 预加载：
MAP.put("alipay", new AlipayProcessor())，避免每次 new 和反射 - 分支极少且稳定（如订单状态 CREATED/PAID/SHIPPED），直接用枚举内置方法：
Status.CREATED.process()，天然无 if
配合工厂方法模式，新增类型不改旧代码
简单工厂用一个类承载所有创建逻辑，新增产品就得改它，违背开闭原则。升级为工厂方法模式后：
- 定义
PaymentFactory接口，声明create()方法 - 每种支付方式对应一个实现类：
AlipayFactory、WechatFactory - 新增渠道？只加一个新工厂类 + 注册到 Spring 或 ServiceLoader，零修改现有代码
此时工厂类本身也变成可插拔的，多态不仅作用于产品，也作用于工厂。
规则引擎等动态场景中，多态让“加载即可用”
像风控规则、导出格式这类需运行时加载的场景：
- 规则基类
Rule定义evaluate()和execute() - 工厂根据配置码（如
"credit_score_rule"）反射加载具体子类 - 引擎统一调用
rule.evaluate()，无需知道背后是 Fico 还是自研模型
只要子类实现了接口，且类路径可达，多态就能完成自动分派。日志、监控、超时控制等横切逻辑，全在父类入口统一处理。
