多态是工厂模式解耦落地的刚性前提，要求工厂返回接口类型对象，业务代码通过接口调用，运行时动态绑定具体实现，新增产品只需实现接口并扩展工厂，无需修改原有代码。
多态是工厂模式真正“活起来”的核心机制，不是锦上添花，而是解耦落地的刚性前提。它让工厂返回的对象能被统一调用，又各自独立实现，业务代码完全不感知变化。
用接口定义行为，而非用类名绑定实现
所有具体产品（如 AlipayProcessor、WechatProcessor）必须实现同一个接口（如 PaymentProcessor），不能只继承某个抽象类或彼此无关。业务类（如 OrderService）只持有该接口引用，方法调用写成 processor.pay(amount) —— 编译期检查接口方法是否存在，运行期才决定执行哪个子类逻辑。
- 工厂方法的返回类型必须是接口或抽象类，绝不能是具体类（如 return new AlipayProcessor() 后赋给 AlipayProcessor 变量）
- 避免在业务层出现 instanceof 或强制类型转换，那是多态失效、解耦失败的明确信号
- 接口比抽象类更推荐：契约轻量、支持多实现、聚焦“能做什么”，不强加“怎么初始化”
工厂只管“交付谁”，不管“怎么做”
工厂内部可以自由选择创建方式：直接 new、加缓存、套代理、走 Spring Bean 查找，甚至读配置动态加载类——这些细节对调用方完全透明。只要它返回的是符合接口规范的对象，多态就能自动接住。
- 推荐工厂方法模式：定义 PaymentFactory 接口，每个渠道对应一个实现类（AlipayFactory、WechatFactory），新增支付方式只需新增工厂实现，不改原有类
- 避免简单工厂的静态方法：它把所有 if-else 塞进一个类，新增渠道就得改源码，违背开闭原则
- 参数建议用字符串（"alipay"）或枚举驱动，而非传类名，防止编译期耦合；工厂内部再做映射
运行时动态绑定，才是多态生效的关键
多态生效的前提是“声明类型 ≠ 实际类型”。必须写成：PaymentProcessor p = factory.create("alipay");，而不是 AlipayProcessor p = ...。前者让 JVM 在运行时根据实际对象类型分派方法调用，调试时能看到变量类型显示为接口，实例却是具体子类。
立即学习“Java免费学习笔记（深入）”；
- 新增一个 ApplePayProcessor，只需两步：实现 PaymentProcessor 接口 + 在对应工厂里加创建分支；所有已有的 pay() 调用点零修改
- 通用逻辑（日志、重试、验签）应抽到装饰器、AOP 或工具类中，不要塞进某个子类，否则破坏一致性与可替换性
- 测试时可直接 mock 接口，覆盖全部实现；规则引擎、支付网关等场景下，这种隔离让单元测试变得轻量可靠
不复杂但容易忽略：多态不是语法糖，是把“变”锁在边界里的设计纪律。工厂提供入口，多态提供调度，两者结合，才能做到加功能不动老代码。
