## 01、痛点

我是老李。前段时间接手一个订单系统，里面有一个 PaymentService，一开始只支持支付宝。代码写得很坦率：

```java
public class OrderPaymentService {
    public void pay(Order order, String payType) {
        if ("ALIPAY".equals(payType)) {
            new AliPayChannel().pay(order);
        }
    }
}
```

后来业务说要加微信支付，小伙子顺手一改：

```java
if ("ALIPAY".equals(payType)) {
    new AliPayChannel().pay(order);
} else if ("WECHAT".equals(payType)) {
    new WechatPayChannel().pay(order);
}
```

再到后面，银联、PayPal、苹果支付都来了。现在这段代码已经不再是一个 if，而是一坨 if / else。新增一个渠道要改老代码；测试一遍所有分支；谁也不敢动核心逻辑。读者如果看过自己项目里类似代码，就知道我在说什么。

问题本质不是 if / else 太多，而是“创建对象”的过程和“使用对象”的过程耦合在一起。调用方被迫知道所有具体支付渠道类，这违反了开闭原则：增加新渠道，必须修改现有类。

> 锐评：一个只有两种支付方式，而且未来三年都不会增加的系统，硬拆十几个类，解决的不是扩展性问题，而是阅读理解问题。

设计模式不是为了让代码看起来更高级，而是当“变化开始失控”时，自然长出的解决方案。

## 02、是什么

工厂方法模式的定义其实就一句话：定义一个创建对象的接口，让子类决定实例化哪个类。

但工程上理解要分三个层次：

第一层：代码复用。把重复的创建逻辑放到工厂里，避免到处 new。

第二层：隔离变化。把“创建哪个对象”这个会变的部分，从调用方剥离出去。

第三层：管理复杂度。让客户端依赖抽象，不依赖具体类，从而降低修改半径。

注意，工厂方法不是简单工厂。简单工厂是一个工厂类里用 if/else 判断，通常违反开闭；工厂方法是把创建延迟到子类，每个子类负责创建一种产品，新增产品不用改原工厂类。

模式不是代码模板，更不是必须套用的公式。它是一种“职责如何拆、变化放在哪里”的思考方式。

看到什么代码坏味道，可以联想到什么模式？这里给一张简洁的创建型映射图：

```text
对象创建逻辑散落各处
        ↓
需要统一创建入口
        ↓
简单工厂（一个工厂类搞定）
        ↓
产品种类持续增加，简单工厂的 if/else 越来越长
        ↓
工厂方法（定义接口，子类决策）
        ↓
产品族一起变化，需要创建一组相关对象
        ↓
抽象工厂
```

工厂方法解决的是“单个产品等级结构”的扩展问题：支付渠道是一种产品等级，订单通知渠道也是。如果你需要同时创建支付渠道和对账渠道，而且它们是相关的产品族，那才考虑抽象工厂。

## 03、为什么

很多开发者学过工厂方法，但真到项目里不会用。原因通常有三个：

误区一：先记模式，再找地方套。拿着工厂望远镜到处找 new，看到 new 就画一个工厂类，结果三行代码变成一个接口加三个类。

误区二：看到 if / else 就认为必须上工厂。if/else 如果只有两个稳定分支，工厂方法反而增加理解成本。

误区三：抽象层越多，架构越高级。其实抽象层是要付费的，每多一层，调试链路就长一层。

判断工厂方法是否值得使用，先回答五个问题：

1. 对象的创建是否会真实变化？
2. 变化是否会持续增加？
3. 新增对象时，是否必须修改旧代码？
4. 多个实现是否存在稳定公共接口？
5. 引入工厂后，理解成本是否低于原来的维护成本？

有一个简单判断公式：

```text
模式收益 = 未来变化成本降低 - 当前抽象复杂度增加
```

如果结果是负数，先别改。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。

工厂方法不是减少代码，而是降低未来修改代码的风险。如果未来根本没有变化，那么简单 new 反而是最好的设计。

## 04、架构

设计模式要按“开发问题”分类，而不是背 GoF 三大类。创建型模式主要解决一个问题：对象怎么创建？

```text
需求变化
   ↓
变化点识别：创建对象的过程会变吗？
   ↓
职责拆分：创建职责和使用职责分离
   ↓
模式选择：
   - 简单工厂：一个工厂类，参数较少，产品固定
   - 工厂方法：产品单个扩展，每个产品对应一个工厂子类
   - 抽象工厂：产品族一起扩展，需要创建一组相关对象
   - 建造者：复杂对象一步步构造
   ↓
接口稳定：客户端依赖工厂接口或产品接口
   ↓
实现扩展：新增产品只需新增工厂子类或新产品类
```

工厂方法模式的核心结构如下：

```text
客户端
   ↓ 依赖
PaymentChannelFactory（抽象工厂接口）
   ↑ 实现
   ├── AliPayChannelFactory
   ├── WechatPayChannelFactory
   └── PayPalChannelFactory
         ↓ 创建
   PaymentChannel（抽象产品接口）
         ↑ 实现
   ├── AliPayChannel
   ├── WechatPayChannel
   └── PayPalChannel
```

相比简单工厂，工厂方法将“创建哪个产品”的决策从工厂类转移到了多个工厂子类中。每个子类只负责一种对象，新增渠道时新增一个子类，不用修改已有工厂代码。

## 05、实战

### 一、业务场景

订单系统需要支持支付宝、微信、银联、PayPal 等多种支付渠道。每个渠道的支付调用方式不同，但都接受 Order 参数，返回支付结果。

### 二、第一版代码

最直观的写法是在 Service 里根据支付类型创建不同渠道对象：

```java
public class OrderPaymentService {
    public PaymentResult pay(Order order, String payType) {
        PaymentChannel channel;
        if ("ALIPAY".equals(payType)) {
            channel = new AliPayChannel();
        } else if ("WECHAT".equals(payType)) {
            channel = new WechatPayChannel();
        } else if ("UNIONPAY".equals(payType)) {
            channel = new UnionPayChannel();
        } else {
            throw new IllegalArgumentException("不支持的支付类型");
        }
        return channel.pay(order);
    }
}
```

### 三、代码开始失控

后来新增 PayPal，必须在这个方法里再加一个 else if。再后来，测试过程中发现，某一个渠道的创建逻辑发生了变化，需要增加配置或初始化，修改的还是这个 Service。每次新增或修改渠道，都要动 OrderPaymentService，回归测试全渠道。更糟的是，好几个地方都复制了这段 if/else，改一处漏一处。

### 四、模式重构

先定义产品接口：

```java
public interface PaymentChannel {
    PaymentResult pay(Order order);
}
```

支付宝、微信等实现这个接口。

再定义工厂接口：

```java
public interface PaymentChannelFactory {
    PaymentChannel createChannel();
    String getPayType();
}
```

支付宝工厂、微信工厂分别实现：

```java
@Component
public class AliPayChannelFactory implements PaymentChannelFactory {
    @Override
    public PaymentChannel createChannel() {
        return new AliPayChannel();
    }
    @Override
    public String getPayType() {
        return "ALIPAY";
    }
}
```

微信工厂同理。

重构后的 OrderPaymentService：

```java
@Service
public class OrderPaymentService {
    private final Map<String, PaymentChannelFactory> factoryMap;

    public OrderPaymentService(Map<String, PaymentChannelFactory> factoryMap) {
        this.factoryMap = factoryMap;
    }

    public PaymentResult pay(Order order, String payType) {
        PaymentChannelFactory factory = factoryMap.get(payType);
        if (factory == null) {
            throw new IllegalArgumentException("不支持的支付类型");
        }
        PaymentChannel channel = factory.createChannel();
        return channel.pay(order);
    }
}
```

Spring 会自动把 PaymentChannelFactory 的所有实现注入到 Map 里，key 是 bean 名称。如果希望 key 是 payType，可以在 @Component 的 value 里指定，或者保留 getPayType 方式。

### 五、结构变化

```text
重构前：
OrderPaymentService
   |
   +-- new AliPayChannel()
   +-- new WechatPayChannel()
   +-- new UnionPayChannel()
   +-- new PayPalChannel()  ← 每次新增都要改这里

重构后：
OrderPaymentService
   ↓ 依赖
PaymentChannelFactory（抽象接口）
   /    |    \
支付宝工厂 微信工厂 PayPal工厂
   ↓      ↓      ↓
支付宝渠道 微信渠道 PayPal渠道
```

### 六、收益

- 新增支付渠道，只需新增一个 PaymentChannel 实现和一个 PaymentChannelFactory 实现，不需要修改 OrderPaymentService。
- 每个工厂子类职责单一，单元测试可以单独覆盖。
- 客户端只依赖抽象工厂接口，代码更加稳定。

### 七、代价

- 类数量增加：每增加一个渠道，可能要多写两个类。
- 阅读链路变长：需要先找到工厂接口，再找到实现类，再到产品实现。
- 如果 Spring 注入 Map 不熟悉，排查问题有一定成本。

### 八、什么时候不要用

- 支付渠道只有支付宝和微信，并且未来几年不会增加：用一个 Map 或简单工厂就足够。
- 创建对象逻辑非常简单，没有初始化差异：直接 new 更直观。
- 不要求统一创建入口，各模块独立处理：不要为了工厂而工厂。

> 锐评：工厂方法不是消灭 new，而是隔离会持续增加的 new。如果 new 不会增加，你就别去动它。

一句记忆口诀：

> “工厂方法：不是消灭 if，而是把创建 if 从调用方搬到工厂子类里。”

### 简单工厂 vs 工厂方法对比

简单工厂用一个工厂类集中判断：

```java
public class PaymentChannelSimpleFactory {
    public static PaymentChannel create(String payType) {
        switch (payType) {
            case "ALIPAY": return new AliPayChannel();
            case "WECHAT": return new WechatPayChannel();
            default: throw new IllegalArgumentException();
        }
    }
}
```

简单工厂优点是实现快、类少；缺点是新增渠道时要修改工厂类，违反开闭原则。工厂方法通过多子类避免修改原类，但类更多。现实项目中，如果渠道数量少且稳定，简单工厂完全够用；如果渠道持续增长或创建逻辑复杂，才切换到工厂方法。

## 06、洞见

工厂方法模式背后有五个更重要的判断力：

洞见一：设计模式真正关注的是“变化”，不是“类”。工厂方法的目的是把“创建哪个类”这个变化点隔离出来。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。如果你只写了一个支付渠道，不要上来就定义工厂接口。

洞见三：工厂方法最重要的价值是降低修改半径。新增渠道时，改动范围从“调用方 + 所有 if/else 复制点”缩小到“新增两个类”。

洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。

洞见五：Spring 框架本身就是工厂方法的大型实践。BeanFactory 是核心工厂，@Bean 方法是工厂方法，FactoryBean 是典型的工厂方法接口。ApplicationContext 通过工厂方法创建并管理 Bean。理解了 Spring 的 Bean 创建机制，也就理解了工厂方法在真实框架中的价值。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

如果你想真正掌握工厂方法，不要背定义，按下面三步走。

第一阶段：先搞清楚三个创建型模式的区别

- 简单工厂：一个工厂类，用 if/switch 创建不同对象。
- 工厂方法：一个工厂接口，多个工厂子类，每个子类负责创建一种对象。
- 抽象工厂：创建一组相关对象，强调产品族。

第二阶段：从自己的项目里找坏味道

重点找这些：

- 一个 Service 里根据类型 new 了十几个不同对象。
- 多个地方复制同样的创建代码。
- 新增一个业务类型，必须修改旧 Service。
- 对象创建前后有大量初始化逻辑。

第三阶段：尝试重构并回答五个问题

1. 变化点是什么？
2. 不用工厂会怎样？
3. 引入工厂增加了什么复杂度？
4. 下一次新增对象，需要修改几个地方？
5. 新人是否更容易理解？

七天实践计划：

Day 1：找一个超过 5 个分支的创建类 if/else。
Day 2：用简单工厂重构，消除调用方直接 new。
Day 3：分析该对象会不会继续增加，如果会，进入 Day 4。
Day 4：用工厂方法重构，定义工厂接口和多个子类。
Day 5：在 Spring 项目里通过 Map 注入所有工厂实现。
Day 6：重新评估：这个抽象真的有必要吗？如果没有变化，回退简单工厂。
Day 7：总结：对比修改前后的新增成本。

## 08、小结

> 工厂方法不是让你多写几个类，而是让“创建什么对象”这个决定不再由调用方硬编码，而是交给稳定的工厂接口和变化的子类。

真正值得学习的不是“工厂方法”这个名字，而是识别变化、隔离变化、降低修改半径的能力。

如果读完这篇文章，你下次看到一坨 new + if/else 时，能先问一句“这个变化会持续吗”，这篇就算没有白写。

## 09、链接与概念说明

**GoF 是什么**：GoF 指《设计模式：可复用面向对象软件的基础》一书的四位作者（Gang of Four），书中总结了 23 种经典设计模式，分为创建型、结构型、行为型三大类。

**创建型模式**：解决对象创建过程中的变化和复杂度。包括简单工厂（不在 GoF 23 种之列，但常用）、工厂方法、抽象工厂、建造者、原型、单例。

**结构型模式**：解决类或对象的组合方式，如适配器、装饰器、代理等。

**行为型模式**：解决对象之间的职责分配和通信，如策略、模板方法、观察者、状态等。

**SOLID 原则与工厂方法**：工厂方法主要体现开闭原则（对扩展开放，对修改关闭）和依赖倒置原则（依赖抽象而非具体类）。这也是为什么工厂方法经常与设计模式一起出现。

**推荐阅读**：

- 《设计模式：可复用面向对象软件的基础》（GoF 经典原著）
- 《Head First 设计模式》（入门友好）
- 《Spring 技术内幕》或 Spring 官方文档中关于 BeanFactory 和 FactoryBean 的章节，结合框架理解工厂方法
- 腾讯云开发者社区中关于 Java 设计模式实践的相关文章

注意：以上只推荐书名和资料类型，不虚构具体链接。

我是老李。前段时间接手一个订单系统，里面有一个 PaymentService，一开始只支持支付宝。代码写得很坦率：

工厂方法模式：从多支付渠道的 new 失控到让子类决定实例化

以多支付渠道创建为例，拆解简单工厂到工厂方法的重构路径，讲清接口抽象、子类决策、Spring 落地和过度设计边界。

架构师

编程语言

架构设计

后端

订单系统支付模块因if/else创建逻辑泛滥导致扩展困难，通过工厂方法模式将创建职责从调用方解耦，实现新增渠道零修改、降低回归测试成本，并附简单工厂对比及实战重构案例。

单元测试

回归测试

代码解释

Java

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

工厂方法模式：从多支付渠道的 new 失控到让子类决定实例化-腾讯云开发者社区-腾讯云

工厂方法模式：从多支付渠道的 new 失控到让子类决定实例化

工厂方法模式：从多支付渠道的 new 失控到让子类决定实例化

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐