创建一个对象最常用的方法就是通过 new 关键字创建出一个对象，但是有的时候这种创建对象的方法并不适用。

建造者模式（又称为构建者模式或生成器模式），属于创建型模式，它用于组装复杂的实例。它可将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。用户只需要指定需要建造的类型就可以得到该类型对应的产品实例 , 不关心建造过程细节。

建造者模式

建造者模式有两种写法，一种是 GoF 中提出的传统的建造者模式写法，一种是现在常用的不带主管类的写法。

不同的实现方式

GoF 中的建造者模式

这里介绍的建造者模式的实现接近于 GoF 的思想。

登场角色：

Product（产品）：我们需要获得的类。
Builder（抽象建造者）：定义用于生成实例的接口（API），准备用于生成实例的方法。
ConcreteBuilder（具体的建造者）：负责实现 Builder 角色接口（API）的类。ConcreteBuilder 还定义了获取最终生成结果（产品）的方法。
Director（监工/指挥者）：负责使用 Builder 角色的接口（API）来生成实例，它并不依赖于 ConcreteBuilder 角色（它只调用在 Builder 角色中被定义的方法）。注意是具体类。组装的具体过程隐藏在 Director 中。
Client（使用者）：使用建造者模式。

在 GoF 书中没有 Client 和 Product 这两个角色，这里只是为了方便理解而引入。

建造者代码如下所示：

public class Product {
  private int param1 = DEFAULT_VALUE;
  private int param2 = DEFAULT_VALUE;
  private int param3 = DEFAULT_VALUE;
}

// 抽象建造者
public abstract class Builder {
	protected Product product = new Product();

	// 一些建造的函数
    public abstract Builder buildPart1();
	public abstract Builder buildPart2();
	public abstract Builder buildPart3();
	public abstract Product getProduct();
}

//具体建造者（可以有多个）
public static class ConcreteBuilder extends Builder {
	/* 具体建造者可以拥有自己的变量 */
    @Override
    public Builder buildPart1() {/***/}
    @Override
    public Builder buildPart2() {/***/}
    @Override
    public Builder buildPart3() {/***/}
    @Override
    public Product getProduct(){
        /* 获取产品前的一些处理 */
		return product;
	}
  }
}

public class Director{
	private Builder builder; // Director 并不关心具体使用了哪个 Builder
	// 使用构造方法或 set 方法传入具体的 builder
	public Director(Builder builder){
		this.builder = builder;
	}

	// 建造工作，保证了一些必选步骤正确执行
	public void build(){
	  /* 省略一些前置处理操作 */
	  builder.buildPart1();
	  builder.buildPart2();
	  builder.buildPart3();
	  /* 省略一些后处理操作 */
    }
}

// 用户调用方式
public class Client{
	public static void main(String[] args){
	    Builder builder = new ConcreteBuilder(); 
		Director director = new Director(builder);
		director.build();
		Product product = builder.getProduct();
	}
}

建造者模式的时序图：

sequenceDiagram
    participant C as Client
    participant D as Director
    participant B as ConcreteBuilder
    activate C
    C ->> B : new
    activate B
    deactivate B
    C ->> D : build
    activate D
    D ->> B : buildPart1
    activate B
    B -->> D : 
    deactivate B
	D ->> B : buildPart2
    activate B
    B -->> D : 
    deactivate B
    D ->> B : buildPart3
    activate B
    B -->> D : 
    deactivate B
    D -->> C : 
    deactivate D
    C ->> B : getProduct
    activate B
    B -->> C : 
    deactivate B
    deactivate C

在建造者模式中，Main 不知道 Builder 类，Director 不知道 ConcreteBuilder 类。可替换性就体现在「只有不知道子类才能替换」。

关于主管类 `Director`

对于上面建造者模式写法，不同文章中的实现也有所不同：

有些写法是使用 Director 获取产品。这种方法让 Director 完全控制构建流程，Builder 只负责部件构造，构建的代码部分实现了复用。用户只需和 Director 交互。
有些写法是像上面文章讲的那样通过 ConcreteBuilder 获取产品，由客户控制建造流程。这种方式会呈现一定的构造灵活度。

严格来说，程序中并不一定需要主管类。客户端代码可直接以特定顺序调用创建步骤。不过，主管类中非常适合放入各种例行构造流程，以便在程序中反复使用。

对于客户端代码来说，主管类完全隐藏了产品构造细节。客户端只需要将一个生成器与主管类关联，然后使用主管类来构造产品，就能从生成器处获得构造结果了。