核心是接口定义行为、工厂交付实现，业务代码仅依赖抽象；多态支撑解耦，所有产品实现统一接口（如paymentprocessor），业务类（如orderservice）只持接口引用；工厂（推荐工厂方法模式）按标识返回实现对象，内部逻辑封装，运行时动态绑定，编译期零感知。
核心是用接口定义行为、工厂交付实现，业务代码只依赖抽象，不碰具体类。多态是解耦的底层支撑——没有它，工厂返回的仍是硬编码的具体类型，解耦就流于形式。
接口统一契约，屏蔽具体实现
所有产品必须实现同一接口（如 PaymentProcessor），而非继承某个具体类。这个接口声明业务所需的核心方法（如 pay(double amount)），不暴露任何实现细节。业务类（如 OrderService）只持有该接口引用，从不声明 AlipayProcessor 或 WechatProcessor 这样的具体类型。
工厂只管“谁来干”，不管“怎么干”
工厂负责根据标识（如字符串 "alipay"）返回符合接口规范的对象，内部创建逻辑（new、配置加载、代理包装、缓存复用等）完全封装。业务层连工厂类名都不需要知道，更不该关心它用了 if-else 还是反射。
- 推荐使用工厂方法模式：定义 PaymentFactory 接口，每个渠道对应一个实现类（
AlipayFactory、WechatFactory） - 避免简单工厂的静态方法：它把所有创建逻辑塞进一个类，新增渠道就得改源码，违背开闭原则
- 工厂本身也应通过接口注入（如 Spring 的
@Qualifier+ 构造器注入），业务类不 new 工厂
运行时动态绑定，编译期零感知
调用 processor.pay(amount) 时，JVM 自动分派到实际对象的方法，编译期完全不知道背后是哪家实现。业务代码里绝不能出现 instanceof 或强制类型转换——那是解耦失败的明确信号。
- 配置驱动更安全：用字符串（如
"alipay"）而非类名传参，防止编译期耦合 - 工厂内部再映射到具体类，新增渠道只需加一个实现类和对应工厂，其他代码不动
- Spring 环境下，优先用接口注入 +
@Bean管理工厂实例，比手动 new 更彻底
一次典型协作流程（以订单支付为例）
OrderService：只调用 factory.create("alipay").pay(order)，它不知道、也不需要知道背后是哪个类
PaymentFactory 接口：声明 create(String type)，不暴露任何实现细节
AlipayFactory：实现 create 方法，内部可 new 实例、加日志、套代理、查缓存——这些变化不影响 OrderService
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
