h5打开以查看为什么需要建造者模式？在GoF设计模式——抽象工厂模式中，抽象工厂解决了"一族产品要风格统一"的问题——一个工厂负责一整套产品，选了工厂就等于选了整套风格。但不管是工厂方法还是抽象工厂，都只管"产出什么"，不管"怎么一步步造出来"。有些对象的构造过程很复杂——不是一句new就能搞定的：// 构造一台电脑：要装 CPU、内存、硬盘，顺序还有讲究 Computer computer = new Computer("Intel i9-13900K", "DDR5 64GB", "NVMe SSD 2TB"); // 问题1：参数多了根本分不清哪个是哪个 // 问题2：有些参数可选，构造函数需要大量重载 // 问题3：构造逻辑散在业务代码中，换个产品就要重写当对象构造变复杂时，直接用构造函数有三个痛点：参数爆炸：十几个参数的构造函数难以阅读，调用方容易传错位置参数可选：有些必填、有些选填，构造函数需要大量重载来覆盖各种组合构建逻辑分散：构造细节混在业务代码中，换种产品就得重写建造者模式把这些细节封装到 Builder 里，调用方不用管里面怎么造。概念建造者模式（Builder Pattern）是创建型设计模式，核心思想：将复杂对象的构建过程与表示分离，用相同的构建步骤创建不同的产品。建造者模式包含四个核心角色：Product（产品）：要构建的复杂对象Builder（抽象建造者）：定义构建步骤的接口，规定"必须做哪几步"ConcreteBuilder（具体建造者）：实现每个步骤，每种产品变体一个Director（指导者）：编排构建顺序，封装"先做什么、后做什么"分工逻辑：Builder 定步骤 → ConcreteBuilder 实现步骤 → Director 排顺序 → Product 出结果。要点：建造者模式解决的是构建过程与表示分离。Director 封装"怎么造"的算法，Builder 决定"造出来长什么样"。同一个 Director 搭配不同 Builder，构建算法不变，但产出不同产品。实现GoF 标准实现：四角色模式GoF 原版，包含完整 Director。适合构建算法固定、产品变体多的场景。// 产品 public class Product { private String partA; private String partB; public void setPartA(String partA) { this.partA = partA; } public void setPartB(String partB) { this.partB = partB; } @Override public String toString() { return "Product{partA='" + partA + "', partB='" + partB + "'}"; } } // 抽象建造者：定义构建步骤 public interface Builder { public void buildPartA(); public void buildPartB(); public Product getResult(); } // 具体建造者 1 public class ConcreteBuilder1 implements Builder { private Product product = new Product(); @Override public void buildPartA() { product.setPartA("PartA-Type1"); } @Override public void buildPartB() { product.setPartB("PartB-Type1"); } @Override public Product getResult() { return product; } } // 具体建造者 2 public class ConcreteBuilder2 implements Builder { private Product product = new Product(); @Override public void buildPartA() { product.setPartA("PartA-Type2"); } @Override public void buildPartB() { product.setPartB("PartB-Type2"); } @Override public Product getResult() { return product; } } // 指导者：封装构建算法（步骤顺序） public class Director { private Builder builder; public Director(Builder builder) { this.builder = builder; } public Product construct() { builder.buildPartA(); // 第一步 builder.buildPartB(); // 第二步 return builder.getResult(); } } // 客户端：同一个 Director，换 Builder 出不同产品 Builder builder1 = new ConcreteBuilder1(); Director director = new Director(builder1); Product product1 = director.construct(); Builder builder2 = new ConcreteBuilder2(); director = new Director(builder2); Product product2 = director.construct();核心价值：Director 封装了固定的构建流程，换一个 Builder 就能产出不同配置，构建算法完全不变。简化实现：链式调用（Fluent Builder）省略 Director，Builder 自身通过return this支持链式调用。这是实际开发中最常用的版本，适合构建过程简单的场景——不需要严格的步骤顺序，只是字段赋值。public class User { private final String name; // 必填 private final int age; // 必填 priva
GoF设计模式——建造者模式
h5打开以查看为什么需要建造者模式？在GoF设计模式——抽象工厂模式中，抽象工厂解决了"一族产品要风格统一"的问题——一个工厂负责一整套产品，选了工厂就等于选了整套风格。但不管是工厂方法还是抽象工厂，都只管"产出什么"，不管"怎么一步步造出来"。有些对象的构造过程很复杂——不是一句new就能搞定的：// 构造一台电脑：要装 CPU、内存、硬盘，顺序还有讲究 Computer computer = new Computer("Intel i9-13900K", "DDR5 64GB", "NVMe SSD 2TB"); // 问题1：参数多了根本分不清哪个是哪个 // 问题2：有些参数可选，构造函数需要大量重载 // 问题3：构造逻辑散在业务代码中，换个产品就要重写当对象构造变复杂时，直接用构造函数有三个痛点：参数爆炸：十几个参数的构造函数难以阅读，调用方容易传错位置参数可选：有些必填、有些选填，构造函数需要大量重载来覆盖各种组合构建逻辑分散：构造细节混在业务代码中，换种产品就得重写建造者模式把这些细节封装到 Builder 里，调用方不用管里面怎么造。概念建造者模式（Builder Pattern）是创建型设计模式，核心思想：将复杂对象的构建过程与表示分离，用相同的构建步骤创建不同的产品。建造者模式包含四个核心角色：Product（产品）：要构建的复杂对象Builder（抽象建造者）：定义构建步骤的接口，规定"必须做哪几步"ConcreteBuilder（具体建造者）：实现每个步骤，每种产品变体一个Director（指导者）：编排构建顺序，封装"先做什么、后做什么"分工逻辑：Builder 定步骤 → ConcreteBuilder 实现步骤 → Director 排顺序 → Product 出结果。要点：建造者模式解决的是构建过程与表示分离。Director 封装"怎么造"的算法，Builder 决定"造出来长什么样"。同一个 Director 搭配不同 Builder，构建算法不变，但产出不同产品。实现GoF 标准实现：四角色模式GoF 原版，包含完整 Director。适合构建算法固定、产品变体多的场景。// 产品 public class Product { private String partA; private String partB; public void setPartA(String partA) { this.partA = partA; } public void setPartB(String partB) { this.partB = partB; } @Override public String toString() { return "Product{partA='" + partA + "', partB='" + partB + "'}"; } } // 抽象建造者：定义构建步骤 public interface Builder { public void buildPartA(); public void buildPartB(); public Product getResult(); } // 具体建造者 1 public class ConcreteBuilder1 implements Builder { private Product product = new Product(); @Override public void buildPartA() { product.setPartA("PartA-Type1"); } @Override public void buildPartB() { product.setPartB("PartB-Type1"); } @Override public Product getResult() { return product; } } // 具体建造者 2 public class ConcreteBuilder2 implements Builder { private Product product = new Product(); @Override public void buildPartA() { product.setPartA("PartA-Type2"); } @Override public void buildPartB() { product.setPartB("PartB-Type2"); } @Override public Product getResult() { return product; } } // 指导者：封装构建算法（步骤顺序） public class Director { private Builder builder; public Director(Builder builder) { this.builder = builder; } public Product construct() { builder.buildPartA(); // 第一步 builder.buildPartB(); // 第二步 return builder.getResult(); } } // 客户端：同一个 Director，换 Builder 出不同产品 Builder builder1 = new ConcreteBuilder1(); Director director = new Director(builder1); Product product1 = director.construct(); Builder builder2 = new ConcreteBuilder2(); director = new Director(builder2); Product product2 = director.construct();核心价值：Director 封装了固定的构建流程，换一个 Builder 就能产出不同配置，构建算法完全不变。简化实现：链式调用（Fluent Builder）省略 Director，Builder 自身通过return this支持链式调用。这是实际开发中最常用的版本，适合构建过程简单的场景——不需要严格的步骤顺序，只是字段赋值。public class User { private final String name; // 必填 private final int age; // 必填 priva
