核心在于用接口定义行为、工厂交付实现，业务代码仅依赖抽象；多态是解耦基础，工厂返回接口类型对象，运行时动态绑定具体实现，配合工厂方法模式与依赖注入实现高内聚低耦合。

核心在于：用接口定义行为，用工厂交付实现，让业务代码只依赖抽象，不碰具体类。

多态是解耦的底层支撑

工厂模式本身不直接解耦，真正起作用的是多态——客户端通过父类型或接口调用方法，运行时才绑定到具体子类。没有多态，工厂返回的还是硬编码的具体类型，解耦就流于形式。

• 所有产品必须实现统一接口（如 PaymentProcessor），而非继承某个具体类
• 业务类（如 OrderService）只持有该接口引用，不声明 AlipayProcessor 或 WechatProcessor
• 调用 processor.pay(amount) 时，JVM 自动分派到实际对象的方法，编译期完全不知道是哪家实现

工厂负责“谁来干”，不负责“怎么干”

工厂只管返回符合接口规范的对象，内部创建逻辑（new、配置、缓存、代理等）对外不可见。业务层连工厂类名都不需要知道，更不该关心它用了 if-else 还是反射。

• 推荐使用工厂方法模式：定义 PaymentFactory 接口，每个支付渠道对应一个实现类（AlipayFactory、WechatFactory）
• 避免简单工厂的静态方法：它把所有创建逻辑塞进一个类，新增渠道就得改源码，违背开闭原则
• 工厂本身也应通过接口注入（如 Spring 的 @Bean 或 ServiceLoader），业务类通过构造器接收工厂，而不是 new 它

一次典型协作流程

以订单支付为例，三者各司其职：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• OrderService：只调用 factory.create("alipay").pay(order)，它不知道、也不需要知道背后是哪个类
• PaymentFactory 接口：声明 create(String type)，不暴露任何实现细节
• AlipayFactory：实现 create 方法，内部可 new 实例、加日志、套代理、查缓存——这些变化不影响 OrderService

关键细节不能漏

解耦不是写个接口就完事，几个实操要点决定效果：

立即学习“Java免费学习笔记（深入）”；

• 工厂返回类型必须是接口，不是具体类；否则多态失效，业务层仍强依赖实现
• 避免在业务代码里做 instanceof 或类型转换，那是解耦失败的信号
• 配置驱动更安全：用字符串（如 "alipay"）而非类名传参，防止编译期耦合；工厂内部再映射到类
• Spring 环境下，优先用 @Qualifier + 接口注入，比手动 new 工厂更彻底