## 01、痛点

想象这样一个场景：你负责的订单中心需要新建一个订单对象。一开始，订单只有订单号、用户ID、商品ID、数量、金额五个字段，构造器写得很干净。

```java
public Order(String orderNo, Long userId, Long skuId, Integer quantity, BigDecimal amount) {
    this.orderNo = orderNo;
    this.userId = userId;
    this.skuId = skuId;
    this.quantity = quantity;
    this.amount = amount;
}
```

后来，业务需要增加支付方式、订单来源、活动ID、优惠金额、收货地址、发票信息、扩展字段等。你不想破坏老代码，于是重载了多个构造器。

```java
public Order(String orderNo, Long userId, Long skuId, Integer quantity, BigDecimal amount, Integer payType) { ... }
public Order(String orderNo, Long userId, Long skuId, Integer quantity, BigDecimal amount, Integer payType, String source) { ... }
public Order(String orderNo, Long userId, Long skuId, Integer quantity, BigDecimal amount, Integer payType, String source, Long activityId) { ... }
// 再往下，参数多到需要数手指头
```

当构造器参数达到 15 个、20 个时，调用方变成这样：

```java
Order order = new Order(orderNo, userId, skuId, quantity, amount, 1, "APP", 888L, null, null, null, address, null, invoice, ext);
```

问题来了：
- 参数太多，顺序极其容易搞错。
- null 值看不懂到底哪个是可选的、哪个是必填的。
- 每次新增字段都要新增一个构造器，老构造器又不能删，类越来越膨胀。
- 新增一个可选参数，调用方可能要在十几处加 null。
- 新人根本不敢动这个核心对象，因为一改构造器，编译错误铺天盖地。

这个场景就是典型的“构建参数爆炸”。它不是“代码写得不高级”，而是“变化开始失控”。设计模式要解决的正是这种失控，而不是让你为只有两个字段的类写个 Builder。

> 锐评：如果订单对象只有三个字段，并且未来不会扩展，而你硬塞一个内部 Builder 类，那不叫设计模式，那叫给自己增加就业机会。

## 02、是什么

建造者模式，从工程视角看，就是把一个复杂对象的“构建过程”和它的“表示”分开，使得同样的构建过程可以创建不同表示。注意，它不是简单地把 setter 串起来，也不是为了少写几个参数而发明的小技巧。

可以分三个层次理解：
- 第一层：代码复用。把重复的“创建步骤”抽到一个 Builder 里，避免到处复制参数校验和赋值逻辑。
- 第二层：隔离变化。对象的字段可能会不断增加或调整，Builder 把这些变化封在内部，外部调用方只需要关心“我需要什么”，而不需要关心“构造器有多少个参数、什么顺序”。
- 第三层：管理复杂度。当对象构造逻辑极其复杂，比如有默认值、有必填校验、有嵌套对象构建、有依赖关系时，Builder 能把复杂度控制在局部，而不是散落在每一个 new 的地方。

模式不是代码模板。建造者模式也不是“必须包含静态内部类 Builder”。它本质上是一种“职责如何拆、变化放在哪里”的思考方式。

看到什么代码坏味道，可以联想到建造者模式？
- 构造器参数超过 5 个且还在增长 → 建造者模式
- 大量重载构造器，且参数顺序容易混乱 → 建造者模式
- 对象有复杂的默认值和可选字段，调用方用大量 null → 建造者模式
- 对象一旦创建就不可变，但字段很多 → 建造者模式

一个简单的字符结构对比：

传统多构造器：
```
OrderService
|
+-- new Order(a, b, c)
+-- new Order(a, b, c, d, e)
+-- new Order(a, b, c, d, e, f, g, ...)
```

使用 Builder 后：
```
OrderService
|
v
Order.Builder
     |
     +-- orderNo()       // 必填
     +-- userId()        // 必填
     +-- payType()       // 可选
     +-- source()        // 可选
     +-- build()         // 统一构建入口
```

可以看出，Builder 不是消灭构造器，而是把变化引导到一个可控的构建入口。

## 03、为什么

很多开发者学过建造者模式，却不清楚什么时候用。常见三个误区：

误区一：先记模式，再找地方套。项目里只要看见多参数类，就急吼吼搞一个 Builder，结果类里十几行 Builder 代码，实际对象才三个字段，徒增干扰。

误区二：把 Builder 当 setter 链。以为 Builder 只是 `new Builder().name("x").age(18).build()` 这种链式调用，却完全不考虑构建过程的封装、必填校验、不可变性。这种 Builder 比直接用 setter 没好多少。

误区三：认为抽象层越多越高级。看到别人用了建造者模式，就觉得自己也得上，否则心慌。实际上，如果一个对象构造过程稳定、简单，静态工厂方法可能是更好的选择。

判断要不要用建造者模式，可以套用几个标准：
1. 变化是否真实存在？字段是否还在持续增加？
2. 参数顺序是否容易被搞错，错误是否隐蔽？
3. 是否经常需要为了可选字段传递 null？
4. 对象是否需要构建后不可变？
5. 引入 Builder 后，调用方理解成本是否低于原构造器？

一个简单判断公式：

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

如果模式收益为负，就不该用。设计模式不是减少代码，而是降低未来修改代码的风险。如果你现在就用 20 个参数构造器，并且每天都要调整字段，那 Builder 很值。但如果对象就三个字段，写个 Builder 反而增加行数，还让新人看不懂。

> 锐评：十行代码就能解决的问题，不要写成一场架构发布会。Builder 不是用来装点门面的，它是用来拯救那些已经被 20 个参数逼疯的开发者。

## 04、架构

创建型模式解决的核心问题是“对象怎么创建”。但不要把它们混为一谈：

- 工厂模式：解决“创建哪个类的对象”，关注的是类型选择，比如根据支付类型返回不同的支付策略实现。
- 建造者模式：解决“如何一步步创建一个复杂对象”，关注的是构建过程，尤其当字段很多、有默认值、有必填约束时。
- 原型模式：解决“通过复制现有对象来创建新对象”，关注的是性能或状态复制。

一个简单的“设计模式问题地图”：

```
需求变化
   ↓
变化点识别：对象创建越来越复杂？
   ↓
职责拆分：把“选哪个类”和“如何创建”分开
   ↓
模式选择：
   ├─ 类型选择多 → 工厂模式
   ├─ 字段多、步骤多、可选多 → 建造者模式
   ├─ 复制现有对象 → 原型模式
   ↓
接口稳定：调用方只需关心 Builder / Factory 入口
   ↓
实现扩展：新增字段/新增类型不影响旧逻辑
```

在 Spring 项目中，建造者模式经常出现。比如 `SqlSessionFactoryBuilder` 构建 `SqlSessionFactory`，需要解析复杂配置；比如 Lombok 的 `@Builder` 注解，它简化了手写 Builder 的代码，但底层思想不变。理解这些框架用法，有助于你知道什么时候该手写 Builder，什么时候该用注解。

## 05、实战

这一章深入一个真实场景：构建一个包含基础信息、支付信息、收货信息、扩展信息的订单对象，要求创建后不可变，且字段日益增长。

**一、业务场景**

订单对象包含：
- 必填：orderNo, userId, skuId, quantity, amount
- 可选：payType, source, activityId, discountAmount, couponId
- 嵌套：Address, Invoice
- 默认值：quantity 默认为 1，source 默认为 APP
- 约束：amount 不能为空且大于 0

**二、第一版代码**

采用多重构造器，字段逐步叠加。随着需求增长，构造器达到 6 个，每个都需要维护参数顺序。

**三、代码开始失控**

调用方写起来像这样：`new Order(orderNo, userId, skuId, quantity, amount, 1, "APP", null, null, null, address, invoice, null)`。每次新增字段，老调用方需要塞 null；参数顺序错误时，编译器不会报错，运行时才可能发现问题。

**四、模式重构**

引入 Builder，代码简化为：

```java
public class Order {
    private final String orderNo;
    private final Long userId;
    private final Long skuId;
    private final Integer quantity;
    private final BigDecimal amount;
    private final Integer payType;
    private final String source;
    // ... 其他字段

    private Order(Builder builder) {
        this.orderNo = builder.orderNo;
        this.userId = builder.userId;
        this.skuId = builder.skuId;
        this.quantity = builder.quantity;
        this.amount = builder.amount;
        this.payType = builder.payType;
        this.source = builder.source;
        // ...
    }

    public static class Builder {
        private String orderNo;
        private Long userId;
        private Long skuId;
        private Integer quantity = 1; // 默认值
        private BigDecimal amount;
        private Integer payType;
        private String source = "APP";

        public Builder(String orderNo, Long userId, Long skuId, BigDecimal amount) {
            // 必填字段放在构造器，可选字段通过方法设置
        }
        public Builder quantity(Integer quantity) { this.quantity = quantity; return this; }
        public Builder payType(Integer payType) { this.payType = payType; return this; }
        public Builder source(String source) { this.source = source; return this; }
        // ...
        public Order build() {
            if (this.amount == null || this.amount.compareTo(BigDecimal.ZERO) <= 0) {
                throw new IllegalArgumentException("amount must be positive");
            }
            return new Order(this);
        }
    }
}
```

**五、结构变化**

字符图：

```
改动前：
调用方直接 new 多个构造器，参数顺序必须手写对齐

改动后：
调用方
    |
    v
Order.Builder
    |-- 必填参数通过构造器传入
    |-- 可选参数通过链式方法设置
    |-- build() 统一校验和创建
```

**六、收益**

- 新增可选字段时，不需要再新增构造器，老调用方无需改动。
- 必填字段与可选字段清楚区分。
- 默认值集中在 Builder 中，不会散落在每个调用点。
- 构建前可以统一做参数校验，创建出的对象更可靠。
- 对象可以设计为不可变（字段 final），线程安全。

**七、代价**

- 类数量增加：每个复杂对象可能多一个 Builder 类（或内部类）。
- 阅读链路变长：需要先看 Builder 再看目标类，理解成本略增。
- 如果对象字段不多，Builder 反而显得冗余。
- 链式调用如果滥用，会让代码像“火车车厢”，难以定位问题。

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

- 对象字段少且稳定（比如 DTO 只有 3 个字段）。
- 对象构建过程没有默认值、没有校验，直接 new + setter 就可以。
- 团队对 Builder 不熟悉，而对象又不太复杂，此时引入可能增加沟通成本。

记忆口诀：“不是给每个类都写 Builder，而是当构造参数多到让你怀疑人生时，再把构建过程收拢到一处。”

## 06、洞见

建造者模式背后，真正要掌握的是几个判断力。

洞见一：设计模式真正关注的是“变化”，不是“类”。建造者模式不是关于如何写一个 Builder 类，而是关于如何隔离“对象字段不断增加”这个变化。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。先让多构造器暴露出问题，再引入 Builder，比提前设计一个复杂 Builder 更可靠。

洞见三：模式最重要的价值是降低修改半径。用 Builder 后，新增字段只需要改 Builder 和目标类，不需要遍历所有调用方，修改半径从 N 个文件缩小到 1-2 个。

洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。如果对象稳定，静态工厂可能比 Builder 更好；如果创建逻辑简单，直接 new 也无妨。

洞见五：很多 Spring 框架内部就是设计模式的大型实践。`SqlSessionFactoryBuilder` 是建造者模式的典型；`BeanDefinitionBuilder` 也是建造者；`ApplicationContext` 初始化时各种 Builder 配合工厂模式。理解这些，能帮你更好地理解框架，但不代表你必须在业务代码里仿照。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。建造者模式再好，也别把它当成新的 if/else，到处乱套。

## 07、行动

如果你想真正掌握建造者模式，建议分三个阶段。

第一阶段：认识业务对象中哪些适合 Builder。可以从这几个特征找：字段超过 5 个、字段还在增长、有默认值和可选字段、创建后不可变。

第二阶段：从自己的项目里找坏味道。找出当前项目里那些参数超过 10 个的构造器，或者大量重载构造器的类。把这些位置标记出来，观察它们是否经常需要修改。

第三阶段：尝试重构。挑一个最严重的复杂对象，按下面步骤操作：
1. 先把所有构造器替换为一个私有构造器，参数为 Builder。
2. 创建一个静态内部类 Builder，包含所有字段。
3. 将必填字段放到 Builder 的构造器中，可选字段通过链式方法设置。
4. 在 build() 中加入统一校验和默认值。
5. 逐步替换外部调用方，让旧的构造器逐渐废弃。

每次重构后，回答五个问题：
1. 变化点是什么？
2. 不使用 Builder 会怎样？
3. 使用 Builder 增加了什么复杂度？
4. 下一次新增字段，需要修改几个地方？
5. 新人是否更容易理解？

七天实践计划：
- Day 1：找出项目中参数最多的构造器，数一数参数个数。
- Day 2：为这个类手写一个 Builder，包含必填与可选字段。
- Day 3：替换现有调用方，保证行为不变。
- Day 4：给 build() 加入参数校验，比如金额必须大于 0。
- Day 5：找出一个可以保留原构造器但必须重载多次的场景，对比 Builder 的收益。
- Day 6：尝试用 Lombok @Builder 实现同一个对象，并比较优缺点。
- Day 7：重新评估：哪些重构其实没有必要？哪些 Builder 用错了地方？

行动部分必须落地：不要只是看，要真的去重构一个类。

## 08、小结

设计模式不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。

建造者模式尤其如此。它最大的价值不是教你写一个 `builder().build()`，而是告诉你：当对象的构建复杂度开始失控时，应该将“如何创建”的复杂度收拢到一处，同时保持调用方的简单和稳定。

真正值得学习的不是 23 个模式名字，而是看到变化、识别变化、隔离变化的能力。

如果读完这篇文章，你找到自己项目里一个 20 参数的构造器，并且成功把它重构成了 Builder，这篇文章就算没有白写。

## 09、链接与概念说明

GoF，即 Gang of Four，四位作者（Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）合著的《设计模式：可复用面向对象软件的基础》，是设计模式的经典来源。书中将 23 种模式分为三大类：

- 创建型模式：关注对象如何创建，包括工厂方法、抽象工厂、建造者、原型、单例。解决“创建过程复杂或需要隐藏创建细节”的问题。
- 结构型模式：关注类和对象的组合，包括适配器、装饰器、代理、外观等。解决“如何组织更大的结构”的问题。
- 行为型模式：关注对象之间的职责分配和交互，包括策略、模板方法、责任链、观察者等。解决“对象之间如何协作”的问题。

SOLID 原则与设计模式紧密相关：
- 单一职责原则：推动我们把构建逻辑从业务对象中分离出来，比如 Builder。
- 开闭原则：对扩展开放、对修改关闭。设计模式如策略、工厂、建造者都帮助实现开闭原则，新增字段或类型不必修改老代码。
- 里氏替换、接口隔离、依赖倒置，则为模式中的抽象和实现提供原则支撑。

“开闭原则”经常和设计模式一起出现，因为设计模式本质上是在为变化预留扩展点，同时尽量不修改已有代码。比如建造者模式在新增可选字段时，老调用方不受影响，正是开闭原则的体现。

推荐继续阅读的经典资料：
- 《设计模式：可复用面向对象软件的基础》——GoF 原著，适合系统理解。
- 《Effective Java》第三版，关于 Builder 的章节非常实用，尤其是不可变对象构建。
- 《重构：改善既有代码的设计》——帮助你识别代码坏味道，知道何时该重构为模式。
- 官方 Java 文档中关于 Lombok @Builder 的说明，可作为工具参考。

（注：以上书籍和资料为经典推荐，不提供虚构链接。）

想象这样一个场景：你负责的订单中心需要新建一个订单对象。一开始，订单只有订单号、用户ID、商品ID、数量、金额五个字段，构造器写得很干净。

从 20 个参数构造器到 Builder：设计模式不是背出来的，是重构出来的

订单对象构建参数爆炸，用建造者模式重构后怎么样？本文结合真实 Java 场景，拆解建造者模式的收益、代价与使用边界，避免为模式而模式。

架构师

编程语言

开发工具

架构设计

建造者模式解决多参数构造器失控问题，将复杂对象构建与表示分离，通过链式方法设置可选字段、统一校验默认值，支持不可变对象，降低新增字段时的修改半径。适用于字段超5个且持续增长、含默认值与嵌套对象的场景，避免参数顺序错误和大量null传递。

代码解释

编译器

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

从 20 个参数构造器到 Builder：设计模式不是背出来的，是重构出来的-腾讯云开发者社区-腾讯云

从 20 个参数构造器到 Builder：设计模式不是背出来的，是重构出来的

从 20 个参数构造器到 Builder：设计模式不是背出来的，是重构出来的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐