## 01、痛点

有一次，我接手一个电商系统的支付模块，看到一段代码心里直接咯噔一下。

这个系统早期只接入了微信支付，代码非常单纯。后来要接入支付宝、银联、云闪付，慢慢地，支付模块开始长出了四个独立工厂：

```java
PayClient client = PayClientFactory.create("wechat");
CallbackParser parser = CallbackParserFactory.create("alipay");
PayRequestBuilder builder = PayRequestBuilderFactory.create("wechat");
RefundClient refundClient = RefundClientFactory.create("alipay");
```

怪吗？看起来每行都合理。

但问题在于，这些对象根本不应该自由组合。微信的 PayClient 必须配合微信的 CallbackParser，支付宝的 PayRequestBuilder 必须配合支付宝的 RefundClient。它们来自同一个支付渠道，签名方式、报文格式、回调验签算法、退款接口规范，都是成套的。

结果有一天线上出事故：

微信支付回调通知到达后，系统用支付宝的 CallbackParser 去验签。编译没问题，运行也没报错，只是验签一直失败，订单状态一直不更新。排查了大半天，最后发现是创建回调解析器时渠道名传成了 alipay。

更难受的是，新增一个支付渠道要同时修改四个工厂类；新人看代码时根本不敢确定哪个对象到底该和哪个对象搭配。一个渠道就像打翻了一盒拼图，散落在不同工厂的 if/else 里。

传统写法下的字符结构大概是这样的：

```
PayClientFactory   CallbackParserFactory   RequestBuilderFactory   RefundClientFactory
      |                    |                        |                      |
   if/else              if/else                 if/else                if/else
```

每个工厂各自为政，产品族的一致性只能靠程序员的小心翼翼来维持。

> 锐评：如果只有两个支付渠道，未来三年也不会增加，那么硬拆出四个抽象工厂加十多个实现类，解决的不是扩展性问题，而是团队招聘和加班时长问题。

设计模式真正解决的，从来不是“代码写得不高级”，而是“变化开始失控”。当你发现某一组对象必须成套出现，一旦配错就会产生线上事故时，抽象工厂模式就不再是书本上的名词，而是自然长出来的解决方案。

## 02、是什么

抽象工厂模式，最常被背成一句话：

“提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。”

听上去像极了普通工厂，甚至像工厂方法多加几个方法。但它的关键点不在“创建对象”，而在“一系列相关或相互依赖”。

先建立两个维度的概念。

产品等级结构：可以理解为“一类产品”。比如支付请求构建器、支付客户端、回调解析器、退款客户端，这些都是不同产品类型。

产品族：同一个渠道下的一组产品。比如微信支付族包含：微信支付请求构建器、微信支付客户端、微信回调解析器、微信退款客户端。

用字符矩阵看非常清楚：

```
                 PayRequestBuilder   PayClient   CallbackParser   RefundClient
微信产品族            ✓                  ✓               ✓                ✓
支付宝产品族          ✓                  ✓               ✓                ✓
银联产品族            ✓                  ✓               ✓                ✓
```

普通工厂方法往往只解决一行，比如只负责创建 PayClient。

抽象工厂则负责整行，它定义一个接口：

```java
public interface PaymentChannelFactory {
    PayRequestBuilder createRequestBuilder();
    PayClient createPayClient();
    CallbackParser createCallbackParser();
    RefundClient createRefundClient();
}
```

每一个具体工厂代表一个完整的产品族。微信工厂创建的四个对象一定都属于微信，支付宝工厂创建的四个对象一定都属于支付宝。

所以，抽象工厂不是“更大的工厂方法”。

工厂方法解决的是：一个产品类型下有多个实现，比如多个支付客户端怎么选择。

抽象工厂解决的是：多个相互依赖的产品类型，必须按族成套创建，不能混用。

很多开发者只看到了“创建接口”，没看到“系列相关对象”这五个字，于是把抽象工厂用成了一个可有可无的壳。

## 03、为什么

为什么很多人学过抽象工厂，却很少在真实项目里用好？

误区一：先记模式，再找地方套。

看到 new 了一个对象，就琢磨是不是该用工厂；看到工厂有多个方法，就觉得自己掌握了抽象工厂。这完全反了。

误区二：把抽象工厂当普通工厂用。

如果只有一种产品类型，硬生生定义出包含多个方法的抽象工厂，那只是把一个 if/else 变成了三个 if/else。

误区三：认为抽象层次越多，架构越高级。

明明只有两个产品族，却设计出接口、抽象类、默认实现、扩展点、配置中心，最后新人看三天都找不到真正发请求的地方。

判断抽象工厂是否值得使用，可以问自己几个问题：

1. 是否存在一组总是需要同时出现、且不能混用的对象？
2. 是否存在多个产品族，未来还会继续增加？
3. 未来更可能新增产品族，而不是频繁增加产品类型？
4. 目前创建逻辑是否已经导致多次错配或修改多处的风险？
5. 引入工厂后，理解和维护成本是否低于原来错配和重复修改的成本？

判断公式可以简化成：

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

如果未来变化成本几乎不会降低，而当前复杂度却实打实增加了，那就不要用。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。一个产品类型只有一个实现，抽象工厂就是给鸡蛋加上密码锁。

设计模式不是用来减少代码行数的，而是用来降低未来修改代码的风险。抽象工厂尤其如此，它的价值不在今天，而在第五个产品族到来时。

## 04、架构

把抽象工厂放在创建型模式的地图中，会更容易理解它到底在解决哪一类问题。

对象创建复杂吗？

```
不复杂
  ↓
直接 new

构造参数很多、可选组合复杂
  ↓
建造者模式

单个产品类型有多个实现
  ↓
工厂方法模式

一组相关对象、多个产品族、必须成套创建
  ↓
抽象工厂模式
```

也就是说，不要因为“对象需要创建”就上工厂，也不要因为“有一组对象”就上抽象工厂。

一个通用的变化处理流程是：

```
需求变化
   ↓
变化点识别
   ↓
职责拆分
   ↓
模式选择
   ↓
接口稳定
   ↓
实现扩展
```

抽象工厂的位置，正是在“一组产品族、多个产品类型”这个交叉点上。

设计抽象工厂时最重要的一件事，是先画出产品族与产品类型的矩阵。

比如支付接入：

```
产品类型：RequestBuilder / PayClient / CallbackParser / RefundClient
产品族：微信 / 支付宝 / 银联 / 云闪付
```

再比如报表导出：

```
产品类型：ReportBuilder / DataFetcher / ExcelWriter / PDFWriter
产品族：订单报表 / 财务报表 / 用户行为报表
```

一旦矩阵画出来，你就能立刻判断：

- 如果未来主要新增产品族，抽象工厂合适。
- 如果未来主要新增产品类型，抽象工厂会很痛苦，因为每新增一个产品类型，所有具体工厂都要改。

这是一个容易被忽略的判断重点。

## 05、实战

### 一、业务场景

支付系统需要支持微信、支付宝两个渠道，未来还要接银联、云闪付。

每个渠道都有四个相互依赖的对象：

- PayRequestBuilder：构建支付请求。
- PayClient：发起支付。
- CallbackParser：解析回调通知。
- RefundClient：发起退款。

这些对象必须严格属于同一个渠道。

### 二、第一版代码

最容易想到的是简单工厂，每个产品类型各自建一个工厂。

```java
public class PayClientFactory {
    public static PayClient create(String channel) {
        if ("wechat".equals(channel)) {
            return new WechatPayClient();
        } else if ("alipay".equals(channel)) {
            return new AlipayPayClient();
        }
        throw new IllegalArgumentException("不支持的渠道");
    }
}
```

另外三个工厂也几乎一样，只是各自返回自己的产品类型。

调用方：

```java
PayClient client = PayClientFactory.create("wechat");
CallbackParser parser = CallbackParserFactory.create("alipay");
```

### 三、代码开始失控

问题在接入两个渠道后迅速暴露：

1. 每个工厂里都有 if/else，四个工厂就是四套条件判断。
2. 新增一个渠道要同时修改四个工厂，很容易漏改。
3. 对象之间的搭配靠人工保证，编译器完全不检查。
4. 渠道名散落在多个地方，拼错也不会提前发现。
5. 新人读代码时，永远不知道微信 PayClient 究竟应该配哪个 CallbackParser。

结构上变成：

```
PayClientFactory      → WechatPayClient / AlipayPayClient
CallbackParserFactory → WechatCallbackParser / AlipayCallbackParser
RequestBuilderFactory → WechatRequestBuilder / AlipayRequestBuilder
RefundClientFactory   → WechatRefundClient / AlipayRefundClient
```

四个工厂平行存在，但产品族边界完全丢失。

### 四、模式重构

先定义四个产品接口：

```java
public interface PayRequestBuilder {
    PayRequest build(PayOrder order);
}

public interface PayClient {
    PayResult pay(PayRequest request);
}

public interface CallbackParser {
    PayCallback parse(String body);
}

public interface RefundClient {
    RefundResult refund(RefundOrder order);
}
```

然后定义抽象工厂接口：

```java
public interface PaymentChannelFactory {
    PayRequestBuilder createRequestBuilder();
    PayClient createPayClient();
    CallbackParser createCallbackParser();
    RefundClient createRefundClient();
}
```

微信具体工厂：

```java
public class WechatPaymentChannelFactory implements PaymentChannelFactory {
    @Override
    public PayRequestBuilder createRequestBuilder() {
        return new WechatPayRequestBuilder();
    }

    @Override
    public PayClient createPayClient() {
        return new WechatPayClient();
    }

    @Override
    public CallbackParser createCallbackParser() {
        return new WechatCallbackParser();
    }

    @Override
    public RefundClient createRefundClient() {
        return new WechatRefundClient();
    }
}
```

支付宝具体工厂类似。

接下来用 Spring 的 Map 注入把具体工厂管理起来：

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

    public PaymentService(Map<String, PaymentChannelFactory> channelFactories) {
        this.channelFactories = channelFactories;
    }

    public PayResult pay(String channel, PayOrder order) {
        PaymentChannelFactory factory = channelFactories.get(channel);
        if (factory == null) {
            throw new IllegalArgumentException("不支持的支付渠道: " + channel);
        }

        PayRequestBuilder builder = factory.createRequestBuilder();
        PayClient client = factory.createPayClient();

        PayRequest request = builder.build(order);
        return client.pay(request);
    }

    public PayCallback handleCallback(String channel, String body) {
        PaymentChannelFactory factory = channelFactories.get(channel);
        if (factory == null) {
            throw new IllegalArgumentException("不支持的支付渠道: " + channel);
        }
        CallbackParser parser = factory.createCallbackParser();
        return parser.parse(body);
    }
}
```

关键点：Spring 会把每个具体工厂 Bean 的名称作为 Map 的 key。比如微信工厂注册为 `wechatPaymentChannelFactory`，调用时用 `channel="wechat"`。实际项目中可以通过 `@Component("wechat")` 指定 channel 名，让 key 直接对应业务标识。

### 五、结构变化

重构前：

```
PaymentService
    ↓
PayClientFactory / CallbackParserFactory / RequestBuilderFactory / RefundClientFactory
    ↓
四条独立的 if/else，产品族边界丢失
```

重构后：

```
PaymentService
    ↓
PaymentChannelFactory
   /         \
微信工厂    支付宝工厂
  |          |
四个成套产品  四个成套产品
```

产品族边界被接口和类型系统固定下来。

### 六、收益

1. 一致性由类型系统保证，微信工厂不可能创建出支付宝回调解析器。
2. 新增一个支付渠道，只需要新增一个具体工厂，不再修改既有工厂。
3. 业务调用方不再面对四套 if/else，渠道判断集中在一处。
4. 单一职责更加明确，具体工厂只负责组装本渠道产品。
5. 单元测试更容易，可以 mock 整个工厂或单独替换某个产品创建方法。

### 七、代价

1. 类数量明显增加，两个渠道就是两个工厂加八个产品实现。
2. 抽象层次增加，简单场景下阅读链路变长。
3. 增加一个新产品类型，比如“对账单下载器”，需要修改抽象工厂接口和所有具体工厂。
4. Spring 容器中的 Map 注入需要团队理解 Bean 命名规则，否则容易找不到工厂。

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

- 只有一个产品族，或者未来不会新增产品族。
- 产品类型变化比产品族变化更频繁。
- 不同对象之间没有强关联，可以独立创建。
- 团队对工厂模式的理解成本明显高于当前维护成本。

> 锐评：抽象工厂管的不是 new，而是产品族不得混用。如果你根本不存在“混用就要爆炸”的问题，就不要提前给代码办演唱会。

## 06、洞见

抽象工厂背后真正值得掌握的，不是它的类结构，而是几个判断力。

洞见一：抽象工厂的核心不是隐藏创建，而是用类型系统锁住产品族一致性。

它通过接口把“微信的对象”和“支付宝的对象”从类型上隔离开。调用方拿到的是一整套来自同一个具体工厂的对象，而不是自己拼出来的组合。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。

如果没有经历过产品族错配的线上事故，没有经历过新增渠道要改四个工厂的痛苦，抽象工厂的接口设计往往会空洞。痛过以后再抽象，接口才真正稳定。

洞见三：设计模式最重要的价值不是减少代码，而是降低修改半径。

抽象工厂让新增产品族的影响范围被限制在“新增一个实现类”上，而不是“修改四个老工厂”。这就是修改半径的缩小。

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

抽象工厂不是所有创建场景的默认答案。如果未来既不会新增产品族，也不会出现混用风险，直接写简单工厂甚至直接 new，可能才是最好的架构。

洞见五：很多 Java 生态的 API 本身就是抽象工厂的实践。

比如 JDBC 的 `Connection`，它可以创建 `Statement`、`PreparedStatement`、`DatabaseMetaData` 等一系列相关对象，而不同数据库驱动提供自己的实现。Spring 的 `BeanFactory` 也是工厂思想的体现，`ApplicationContext` 负责创建并管理一系列相互依赖的 Bean。

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

## 07、行动

如果你想真正掌握抽象工厂，可以按三个阶段走。

第一阶段：搞懂工厂演进。

先弄明白简单工厂、工厂方法、抽象工厂分别解决什么问题。重点不是背定义，而是画产品族与产品类型矩阵。

第二阶段：从自己项目里找线索。

寻找那些总是成组出现、且不能混用的对象：

- 支付渠道的请求构建器、支付客户端、回调解析器、退款客户端。
- 消息通道的模板构建器、发送器、回执解析器。
- 报表导出的数据获取器、样式构建器、Excel/PDF 写入器。
- 数据库方言的连接器、命令构造器、分页 SQL 生成器。

第三阶段：尝试重构。

每次重构时，必须回答五个问题：

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

一个七天实践计划：

Day 1：找出项目中一组成对出现的对象，比如导出 Excel 与 PDF 的 Builder、Writer、Styler。

Day 2：画出产品族与产品类型矩阵，标出哪些组合可能错配。

Day 3：看看当前代码是用几个简单工厂或 if/else 写的，记录痛点。

Day 4：定义一个包含所有产品类型的抽象工厂接口。

Day 5：为每个产品族实现一个具体工厂，并用 Spring Map 注入替换选择逻辑。

Day 6：写单元测试，验证同一个工厂创建的对象总是来自同一个产品族。

Day 7：反向评估：如果未来不会新增产品族，这次重构是否值得？如果产品类型会频繁增加，是否应该回退到更轻量的方案？

这个第七天，往往比前六天更重要。

## 08、小结

“抽象工厂不是为了隐藏 new，而是为了让你在接入第五个支付渠道时，不会把微信的请求构建器塞给支付宝的回调解析器。”

设计模式真正值得学习的，从来不是那二十三个名字，而是看到变化、识别变化、隔离变化的能力。抽象工厂只是这种能力在“产品族”场景下的一次具体落地。

当你下一次再看到四个工厂各自 if/else、彼此拼命错配时，能停下来画一张产品族矩阵，然后决定是引入抽象工厂，还是继续保持简单，这比会背十种设计模式定义有用得多。

如果读完这篇文章，你少写了一个错配对象、少查一次线上回调验签失败，这篇文章就算没有白写。

## 09、链接与概念说明

GoF 是什么：

GoF 指 Gang of Four，即四位作者 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides。他们在 1994 年出版的《设计模式：可复用面向对象软件的基础》中总结了 23 种经典设计模式，是这一领域最经典的参考资料之一。

创建型、结构型、行为型：

创建型模式关注对象的创建过程，比如抽象工厂、工厂方法、建造者、单例等。结构型模式关注类和对象的组合方式，比如适配器、装饰器、代理等。行为型模式关注对象之间的职责分配和交互方式，比如策略、责任链、模板方法、观察者等。

SOLID 原则与设计模式的关系：

抽象工厂非常依赖开闭原则和依赖倒置原则。开闭原则要求对扩展开放、对修改关闭，抽象工厂通过新增具体工厂支持新产品族，而不需要修改业务代码；依赖倒置原则要求高层模块依赖抽象，不依赖具体实现，PaymentService 只依赖 PaymentChannelFactory 接口，不依赖微信或支付宝具体工厂。

为什么开闭原则经常和设计模式一起出现：

设计模式的很多价值最终都指向开闭原则。一个设计如果没有让新增变化更安全、更局部，那它可能只是在增加结构复杂度，而不是真正解决问题。

推荐延伸阅读：

- 《设计模式：可复用面向对象软件的基础》
- 《Head First 设计模式》
- Refactoring Guru 网站上的设计模式概念与示例

这些资料可以帮助你更系统地理解抽象工厂的来龙去脉，但真正的掌握仍然要回到你自己的业务矩阵和重构实践中。

这个系统早期只接入了微信支付，代码非常单纯。后来要接入支付宝、银联、云闪付，慢慢地，支付模块开始长出了四个独立工厂：

抽象工厂模式：别等微信请求构建器塞进支付宝回调，才想起产品族一致性

从支付渠道接入中产品族错配的真实事故出发，讲透抽象工厂是什么、什么时候该用、怎么从一坨 if/else 重构到产品族工厂，以及它新增产品类型时的代价。

架构师

编程语言

架构设计

后端

抽象工厂模式解决一组相关对象必须成套创建且不能混用的问题，通过产品族矩阵和类型系统锁定一致性，降低新增渠道时的修改半径。当多产品族、强关联对象、未来扩展是痛点时，比普通工厂更可靠，但若变化少则无需过度设计。

单元测试

代码解释

数据库

编译器

容器

Java

腾讯云BI特惠9.9元起！


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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

抽象工厂模式：别等微信请求构建器塞进支付宝回调，才想起产品族一致性-腾讯云开发者社区-腾讯云

抽象工厂模式：别等微信请求构建器塞进支付宝回调，才想起产品族一致性

抽象工厂模式：别等微信请求构建器塞进支付宝回调，才想起产品族一致性

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐