1.4 建造者模式

建造者模式（Builder）把“一个复杂对象的构造过程”和“它的最终表示”分开。当一个对象有很多参数，尤其是很多可选参数时，它能把混乱的构造收敛成一条清晰可读的链式调用。

想象构造一个汉堡：要不要芝士？加不加培根？酱汁选哪种？用构造函数表达这些组合会很糟糕。建造者让你“点一样加一样”，最后 build() 一次性产出成品。

下面的汉堡建造者：每勾选一种配料，就向链式调用追加一步，实时看到生成的代码和最终成品。

它解决的真正痛点：伸缩构造函数

没有建造者时，应对“很多可选参数”通常有两条糟糕的路：

• 伸缩构造函数（telescoping constructor）：写一堆重载——Pizza(size)、Pizza(size, cheese)、Pizza(size, cheese, olives)……可选项一多就组合爆炸，调用时还容易把参数顺序传错。

• JavaBeans（一堆 setter）：对象在构造过程中处于“半成品”状态，且无法做成不可变。

建造者两者兼得：链式可读、参数有名字、最终对象可以是不可变的。

HttpRequest req = new HttpRequest.Builder("https://api.example.com")
        .method("POST")
        .header("Content-Type", "application/json")
        .timeout(5000)
        .build();   // 一次性产出不可变对象

下面的对照器用一个“需要维护的入口数量”指标，让你看到可选参数从 1 增加到 5 时，伸缩构造函数如何按 $2^n$ 爆炸，而建造者始终是 1。

建造者 vs 工厂

两者都关乎“创建对象”，但回答的问题不同：

一句话：当“选哪个类”是难点时用工厂；当“怎么把一个对象拼出来”是难点时用建造者。

什么时候别用

如果对象只有两三个必填参数、没有可选项，建造者就是过度设计——一个普通构造函数更直接。建造者的甜区是可选参数多、构造步骤复杂、希望成品不可变。