【西瓜带你学设计模式 | 第五期 - 建造者模式】建造者模式 —— 产品构建实现、优缺点与适用场景及模式区别

文章目录

- 前言
- 1. 建造者模式是什么？
- 1. 它解决什么问题？
- - 2.1 构造函数参数过多（可读性差、维护困难）
  - 2.2 构建步骤固定但细节可变（复用构建流程）
  - 2.3 避免"上帝对象式"构建逻辑
- 1. 核心结构
- 1. 示例
- 4.1 产品：Computer
- 4.2 抽象建造者：ComputerBuilder
- 4.3 具体建造者：GamingComputerBuilder / OfficeComputerBuilder
- 4.4 导演者：ComputerDirector（可选）
- 4.5 客户端使用
- 1. 建造者模式的关键点
- 1. 优缺点
- - 优点
  - 缺点
- 1. 注意事项
- 1. 适用场景总结
- 1. 与其他模式的区别
- - 9.1 建造者 vs 工厂方法/抽象工厂
  - 9.2 建造者 vs 原型模式
- 1. 总结

前言

在软件开发中，面对"一个复杂对象的构建过程往往很复杂，而且不同场景下构建步骤又可能不同"时，我们常常会遇到两类问题：

构建步骤写进构造函数里，导致构造函数越来越臃肿（参数爆炸、难读）
你想复用同一构建流程的"骨架"，但又要灵活替换某些步骤

这时就可以用 建造者模式（Builder Pattern） 来解决：

把"构建过程"与"表示/产出对象"解耦，让同一个构建流程可以按需选择构建细节。

1. 建造者模式是什么？

建造者模式 ：将一个复杂对象的构建过程抽象出来，用**建造者（Builder）**逐步创建对象；最终由建造者产出完整对象。

客户端不直接 new 具体复杂对象，而是通过"导演者（Director）/建造者"完成构建。

一句话理解：

导演者（可选）负责"怎么搭建"
建造者负责"搭建细节"
产品负责"最终长什么样"

2. 它解决什么问题？

建造者模式主要解决以下痛点：

2.1 构造函数参数过多（可读性差、维护困难）

例如一个 Computer：

CPU、内存、硬盘、GPU、是否支持 WiFi、是否带操作系统......
如果全放构造函数里，会越来越难用。

2.2 构建步骤固定但细节可变（复用构建流程）

你可能每次都要"先装硬件、再安装系统、最后封装"，但某些环节的实现不同。

建造者可以复用流程骨架，并把"变化点"封装在具体建造者里。

2.3 避免"上帝对象式"构建逻辑

把所有 new 和配置逻辑堆到客户端，会导致：

业务代码臃肿
构建细节难复用
修改某个部件逻辑影响范围扩大

建造者模式把这些变动"隔离"起来。

3. 核心结构

建造者模式通常包含：

产品（Product）
- 被构建的复杂对象（例如 House、Computer）
抽象建造者（Builder）
- 声明"构建过程"的各个步骤（buildPartA() / buildPartB()）
- 提供一个方法 getResult() 返回最终产品
具体建造者（ConcreteBuilder）
- 实现抽象建造者的步骤，形成不同风格/规格的产品
导演者（Director，可选）
- 定义构建顺序（使用建造者执行步骤）
- 用于复用"构建流程"

4. 示例

下面用"组装电脑"来演示：不同品牌/不同配置的组装过程可以复用流程骨架，但细节不同。

4.1 产品：Computer

java 复制代码

import java.util.ArrayList;
import java.util.List;

public class Computer {
    private final List<String> parts = new ArrayList<>();

    public void addPart(String part) {
        parts.add(part);
    }

    public void show() {
        System.out.println("Computer Parts: " + parts);
    }
}

4.2 抽象建造者：ComputerBuilder

java 复制代码

public abstract class ComputerBuilder {
    protected Computer computer = new Computer();

    // 构建步骤：不同建造者会给出不同实现/选择
    public abstract void buildCPU();
    public abstract void buildRAM();
    public abstract void buildSSD();
    public abstract void buildGPU();

    public Computer getResult() {
        return computer;
    }
}

4.3 具体建造者：GamingComputerBuilder / OfficeComputerBuilder

java 复制代码

public class GamingComputerBuilder extends ComputerBuilder {
    @Override
    public void buildCPU() { computer.addPart("Gaming CPU (High Performance)"); }

    @Override
    public void buildRAM() { computer.addPart("32GB RAM"); }

    @Override
    public void buildSSD() { computer.addPart("1TB SSD"); }

    @Override
    public void buildGPU() { computer.addPart("RTX 4070 GPU"); }
}

public class OfficeComputerBuilder extends ComputerBuilder {
    @Override
    public void buildCPU() { computer.addPart("Office CPU (Efficient)"); }

    @Override
    public void buildRAM() { computer.addPart("16GB RAM"); }

    @Override
    public void buildSSD() { computer.addPart("512GB SSD"); }

    @Override
    public void buildGPU() { computer.addPart("Integrated GPU"); }
}

4.4 导演者：ComputerDirector（可选）

java 复制代码

public class ComputerDirector {
    private final ComputerBuilder builder;

    public ComputerDirector(ComputerBuilder builder) {
        this.builder = builder;
    }

    // 固定的构建顺序（复用流程骨架）
    public void construct() {
        builder.buildCPU();
        builder.buildRAM();
        builder.buildSSD();
        builder.buildGPU();
    }

    public Computer getComputer() {
        return builder.getResult();
    }
}

4.5 客户端使用

java 复制代码

public class Main {
    public static void main(String[] args) {
        ComputerDirector director = new ComputerDirector(new GamingComputerBuilder());
        director.construct();
        director.getComputer().show();
    }
}

5. 建造者模式的关键点

你可以看到它的价值在于：

把"创建过程"拆成多个步骤
把"产品最终表示"放到 Product 中
通过不同的 ConcreteBuilder 产出不同配置
Director 复用构建顺序（可选）

所以它特别适合那种：

"同一个复杂对象的构建过程可能变化，但构建顺序/流程可以复用或部分复用。"

6. 优缺点

优点

更好的可读性与可维护性
- 构建步骤清晰分离，避免构造函数参数爆炸
解耦构建过程与产品表示
- 客户端不用关心内部如何组装
扩展方便
- 新增一种配置：新增一个具体建造者即可
适合复杂对象创建
- 特别是有很多可选部件、构建步骤多的情况

缺点

类会变多
- 至少会有 Builder + Product + 若干 ConcreteBuilder
如果对象构建很简单
- 引入建造者可能是"过度设计"

7. 注意事项

避免把 Director 做成"上帝类"
- Director 应该只负责顺序，不要承载过多业务细节
Builder 不要复用导致状态污染
- 通常 builder 内部有 computer 状态，构建完后要确保不会被意外复用到下一次
和链式参数对比
- Java 里很多人用"链式 set + build()"实现类似 Builder 的效果；那也属于建造者思想的一种变体

8. 适用场景总结

当你满足以下条件时，建造者模式很合适：

需要创建的对象复杂（步骤多、部件多、可选项多）
创建过程与表示（对象本身）需要解耦
不同配置/不同规格的对象构建过程存在差异
希望复用构建流程（用 Director）

9. 与其他模式的区别

9.1 建造者 vs 工厂方法/抽象工厂

工厂（Factory）：更强调"创建哪一个产品"（通常一步到位）
建造者（Builder）：更强调"怎么一步步构建复杂产品"（步骤化）

一句话：

工厂解决"new 谁"，建造者解决"怎么搭"。

9.2 建造者 vs 原型模式

原型：通过复制现有对象快速创建新对象
建造者：通过步骤构建，通常对构建过程更可控

10. 总结

建造者模式通过"抽象建造者 + 具体建造者 +（可选）导演者"把复杂对象的构建步骤抽离出来，使得构建过程与产品表示解耦，从而让不同配置的复杂对象创建变得清晰、可扩展、易维护。