前言

为什么需要建造者模式？说起来，

在 GoF设计模式——抽象工厂模式 中。抽象工厂解决了“一族产品要风格统一”的问题——一个工厂负责一整套产品，选了工厂就等于选了整套风格。

但不管是工厂方法还是抽象工厂。都只管“产出什么”，不管“怎么一步步造出来”。有些对象的构造过程很复杂——不是一句 new 就能搞定的：

// 构造一台电脑：要装 CPU、内存、硬盘，顺序还有讲究
Computer computer = new Computer;// 问题1：参数多了根本分不清哪个是哪个
// 问题2：有些参数可选，构造函数需要大量重载
// 问题3：构造逻辑散在业务代码中。换个产品就要重写

当对象构造变复杂时直接用构造函数会出现以下痛点：

• 参数爆炸十几个参数的构造函数难以阅读，调用方容易传错位置。其实，
• 参数可选必填、选填混杂。需要大量重载来覆盖各种组合。
• 建立逻辑分散构造细节混在业务代码中，换种产品就得重写。

概念

建造者模式是创建型设计模式，主要思想是将复杂对象的建立过程与表示分离用相同的建立步骤创建不同的产品。

四个主要角色：

• Product: 要建立的复杂对象。
• Builder: 定义建立步骤的接口，规定“必须做哪几步”。
• ConcreteBuilder: 实现每个步骤，每种产品变体对应一个实现。
• Director: 编排建立顺序，封装“先做什么、后做什么”。

classDiagram
direction BT
class Director {
-Builder builder
+Director
+construct Product
}
class Builder {

+buildPartA void
+buildPartB void
+getResult Product
}
class ConcreteBuilder1 {
-Product product
+buildPartA void
+buildPartB void
+getResult Product
}
class ConcreteBuilder2 {
-Product product
+buildPartA void
+buildPartB void
+getResult Product
}
class Product {
-partA String
-partB String
}
Director --> Builder : 使用
ConcreteBuilder1 ..|> Builder : 实现
ConcreteBuilder2 ..|> Builder : 实现
ConcreteBuilder1 ..> Product : 创建
ConcreteBuilder2 ..> Product : 创建

要点：

• The construction process is separated from representation.
• The Director encapsulates “how to build”;Builder/C​oncreteBuilders decide “what it looks like”.
• The same Director,different B​uilders → same algorithm。different products.

实现

GoF 标准实现：四角色模式

This version contains a full Director. It suits scenarios where construction algorithm is fixed but re are many product variants.

// 产品
public class Product {
private String partA;private String partB;public void setPartA { this.partA = partA;怎么说呢，}
public void setPartB { this.partB = partB;}
@Override public String toString {
return "Product{partA='" + partA + "',partB='" + partB + "'}";话说回来，}
}
// 抽象建造者：定义建立步骤
public interface Builder {
void buildPartA;void buildPartB;Product getResult;}
// 具体建造者 1
public class ConcreteBuilder1 implements Builder {
private Product product = new Product;@Override public void buildPartA { product.setPartA;}
@Override public void buildPartB { product.setPartB;}
@Override public Product getResult { return product;}
}
// 具体建造者 2
public class ConcreteBuilder2 implements Builder {
private Product product = new Product;@Override public void buildPartA { product.setPartA;}
@Override public void buildPartB { product.setPartB;}
@Override public Product getResult { return product;其实，}
}
// 指导者：封装固定的建立流程
public class Director {
private Builder builder;说起来，public Director { this.builder = builder;}
public Product construct {
builder.buildPartA;// 第一步先
builder.buildPartB;// 接下来
return builder.getResult;怎么说呢，}}
// 客户端示例
public class Client {
public static void main {
Builder b1 = new ConcreteBuilder1;其实，Director d1 = new Director;System.out.println);老实说，Builder b2 = new ConcreteBuilder2;Director d2 = new Director;System.out.println);}
}

从简化实现来看，链式调用

A pragmatic variant that drops Director**. The builder itself returns `this`** so you can chain calls. This is most common form in day‑to‑day development.

public class User {
private final String name;// 必填
private final int age;// 必填
private final String email;按理说，// 可选
private final String phone;// 可选
private final String address;// 可选
private User {
this.name = builder.name;this.age = builder.age;
说起来，this.email = builder.email;this.phone = builder.phone;this.address = builder.address;}
public static class Builder {
private final String name;private final int age;private String email = "";怎么说呢，private String phone = "";private String address = "";public Builder {
this.name = name;this.age = age;}
public Builder email { this.email = email;return this，}
public Builder phone { this.phone = phone;return this，}
public Builder address { this.address = address;return this，}
public User build {
if {
throw new IllegalArgumentException;}
return new User;按理说，} }}
// 使用示例
User user = new User.Builder
.email
.phone
.address
.build;

Lombok @Builder：注解驱动

Lombok 自动为类生成完整的链式 @Builder. It’s essentially “auto‑generated” version of fluent builder above.

import lombok.Builder;
import lombok.ToString;
@Builder @ToString
public class User {
private String name;private int age;private String email;老实说，private String phone;}
// 调用方式
User user = User.builder
.name
.age
.email
.build;

Lombok 编译后大致生成如下代码：

public class User {
private String name;private int age;...
public static UserBuilder builder { return new UserBuilder;}
public static class UserBuilder {
private String name;private int age;...
UserBuilder {}
public UserBuilder name{ this.name=name;return this，}
...
public User build{ return new User;}
}}

怎么选

说到记忆口诀，

何时必须手写 Builder？按理说，

If your construction involves more than plain field assignment—e.g.,state accumulation。string拼接、条件过滤—n Lombok’s pure field‑builder cannot cope.

// SQL 查询生成器 – 有状态+拼接逻辑，不适合 @Builder
public class SqlQueryBuilder {
private String table;private List conditions = new ArrayList<>;private List columns = new ArrayList<>;public SqlQueryBuilder from{ this.table=t;return this，}
public SqlQueryBuilder select{ columns.addAll);return this，}
public SqlQueryBuilder where{ conditions.add;return this，}
public String build{
StringJoiner sj=new StringJoiner;sj.add)，if){
sj.add);}
return sj.toString;}}
// 使用示例
String sql=new SqlQueryBuilder
.select
.from
.where
.where
.build;

The core problem solved by Builder pattern is **how to assemble a complex object step by step** while keeping construction logic isolated from client code.

说到适用场景。

• * 参数数量 ≥ 4 且多数可选* – 构造函数重载太多，用链式更直观。怎么说呢，
• * 建立步骤有顺序依赖* – 必须先 A 再 B 时用 Director 明确顺序。
• * 想要不可变对象* – 所有属性只能在 build 前修改，一旦返回即不可变。
• * 同一流程产出不同产品* – 用不同 ConcreteBuilder 替换，实现复用。
• * 参数校验统一集中* – 在 build/getResult 中一次完成检查。
\

至于不适用场景，

\

• 简单对象 ：直接使用普通构造函数。

• 完全没有顺序依赖的对象——此时 Fluent/Setter 已足够。

快速对比 

\

维度<\/th>\

抽象工厂<\/th>\

建造者<\/th>\

<\/tr> <\/ad>

关注点<\/b>: 产品之间兼容性 <\/t d><\

... ...

练习题目 

---