多态是工厂模式解耦的必要条件，工厂方法返回接口类型，业务层面向接口编程，运行时动态绑定实现类，新增支付方式无需修改业务逻辑。
多态是工厂模式真正实现解耦的底层支撑，不是锦上添花，而是必要条件。没有多态，工厂返回的只是具体类实例，业务代码仍得硬编码类型；有了多态，业务层只面向接口编程，运行时才决定调用哪个子类方法。
工厂靠多态返回抽象，不暴露具体实现
工厂方法（如 createPaymentProcessor()）的返回类型必须是接口或抽象类（如 PaymentProcessor），而不是 AlipayProcessor 或 WechatProcessor。这样客户端拿到的是统一类型引用，编译期完全不知道背后是谁。
- 业务类（如 OrderService）只持有 PaymentProcessor 引用，调用 pay(amount) 时由 JVM 动态绑定到实际对象
- 新增支付方式只需新增实现类 + 对应工厂，无需修改已有业务逻辑
- 若工厂返回具体类，业务代码就可能写成 AlipayProcessor p = factory.create(...)，多态失效，解耦崩塌
业务代码靠多态调用，不关心对象真实身份
客户端通过父类型引用调用方法，JVM 在运行时查虚方法表（vtable），根据对象实际类型定位具体实现。这个过程对开发者透明，但决定了行为是否可替换。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 禁止在业务中使用 instanceof 或强制转型——这是多态被破坏的明确信号
- 策略切换零成本：换一个工厂实现，或改一行配置字符串（如从 "alipay" 改为 "paypal"），行为自动变化
- 测试更简单：可轻松注入 Mock 实现，无需改动被测类结构
工厂自身也靠多态组织，支持灵活扩展
推荐用工厂方法模式（而非静态简单工厂），即定义 PaymentFactory 接口，每个渠道对应一个实现类（AlipayFactory、WechatFactory）。这些具体工厂本身也是多态参与者。
- 抽象工厂接口声明 create() 方法，返回抽象产品，不暴露创建细节
- 各具体工厂内部可自由决定如何构建实例：new、缓存、代理、装饰，都不影响上层
- Spring 环境下可通过 @Qualifier 注入不同工厂 Bean，彻底消除 new 和字符串硬编码
关键细节决定多态是否真正生效
光写个接口和几个实现类不够，以下三点漏掉任一，多态就形同虚设：
- 所有产品类必须实现同一接口（不能仅靠继承某个基类，否则无法跨继承体系复用）
- 工厂方法参数建议用配置键（如字符串 "alipay"），而非类名或 Class 对象，避免编译期耦合
- 业务类应通过构造器或 setter 接收工厂依赖，而不是自己 new 工厂——否则工厂的多态封装意义归零
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
