目录
一、引言
想必大家都听说过问界发布会上的“遥遥领先”。那么，就以问界为例来展开下面的讨论。
问界的组装过程极为复杂，涉及众多零部件和精细工序。从电机、底盘、车身到内饰，每一个部件都经过精心设计和精确组装，以确保产品在性能和品质上“遥遥领先同行”。在制造工厂中，有一个专门的团队负责将成千上万的零部件按照既定顺序和规则组装成一辆完整的问界。这个团队就如同“建造者”，遵循一套固定流程：先安装电机，接着是底盘，然后是车身，最后是内饰。每个步骤都有专人负责，他们专注于自己负责的部分，而整个组装过程则由一位“指挥者”来协调和控制。
这种分工明确、步骤清晰的组装方式，正是我们要探讨的设计模式——建造者模式（Builder Pattern）的生动体现。
二、核心概念
建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。英文的描述是：Separate the construction of a complex object from its representation so that the same construction process can create different representations. 通俗来讲，就是将做什么与怎么做分离。
建造者模式是一种对象创建型模式，它将客户端与包含多个部件的复杂对象的创建过程分离，客户端无需知道最终产品的创建细节。建造者的根本任务就是将各个部件组装起来，得到一个完整的产品，最终交付给客户。
三、模式结构
建造者模式包含以下4个角色。
- Product(产品)：最终要构建的复杂对象，产品类中包含产品的属性和方法。
- Builder(抽象建造者)：定义各种接口，这个类中一般包含两类方法，一类方法是buildPartX()，用于创建复杂对象的各个部件；另一类方法是getResult()，用于返回复杂对象。
- ConcreteBuilder(具体建造者)：实现Builder的接口，并且每个具体的建造者都要new出一个复杂对象，这很好理解，建造者的根本任务就是要生产产品，new出对象后再对其属性进行设置即可得到产品。
- Director(指挥者)：指挥者又称为导演类，负责安排复杂对象的建造次序，并将构建好的产品交付给客户端。之所以选择让指挥者将产品交付给客户端，而不是让建造者交付，是因为不想让客户端深入到具体的建造类中。
四、代码实现
以生产汽车为例，为了简化代码，只保留了汽车的品牌和车身颜色两个属性。
//builderPattern.hpp
#ifndef BUILDER_PATTERN_HPP
#define BUILDER_PATTERN_HPP
#include <string>
#include <iostream>
//产品类，包含了产品的属性和方法
class Car {
public:
void setModle(const std::string& model) {
_model = model;
}
void setColor(const std::string& color) {
_color = color;
}
void display() {
std::cout << "Car Model: " << _model << ", Color: " << _color << std::endl;
}
private:
std::string _model;
std::string _color;
};
//抽象建造者，定义了建造产品的方法
//指挥者通过调整建造者中的建造顺序，可以创建不同的产品，只是本例没有体现出顺序的差别
class CarBuilder {
public:
virtual void buildModle(const std::string& model) = 0;
virtual void buildColor(const std::string& color) = 0;
virtual Car* getCar() = 0;
};
//具体建造者，实现了抽象建造者中的方法
//每个具体建造者中，都要包含一个产品
class ConcreteCarBuilder : public CarBuilder {
public:
ConcreteCarBuilder() : _car(new Car()) {}
void buildModle(const std::string& model) override {
_car->setModle(model);
}
void buildColor(const std::string& color) override {
_car->setColor(color);
}
Car* getCar() override {
return _car;
}
private:
Car* _car;
};
//客户端直接与指挥者之间打交道，不深入到具体的建造者类中
//所以指挥者直接就返回了产品
class Director {
public:
Director(CarBuilder* builder) :_builder(builder) {}
void setBuilder(CarBuilder* builder) { _builder = builder;}
Car* constructCar(const std::string& model, const std::string& color) {
_builder->buildModle(model);
_builder->buildColor(color);
return _builder->getCar();
}
private:
CarBuilder* _builder;
};
#endif // BUILDER_PATTERN_HPP
//test.cc
#include "builderPattern.hpp"
int main()
{
ConcreteCarBuilder carBuilder;
Director director(&carBuilder);
Car* car = director.constructCar("BMW", "RED");
car->display();
std::cout << "------------------------" << std::endl;
ConcreteCarBuilder carBuilder2;
director.setBuilder(&carBuilder2);//复用指挥者
Car* car2 = director.constructCar("Audi", "BLACK");
car2->display();
return 0;
}
五、优缺点以及适用环境
5.1 建造者模式的优点
- 在建造者模式中，客户端不必知道产品内部的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
- 每一个具体建造者都相对独立，与其他具体建造者无关，因此可以很方便的替换具体建造者或增加新的具体建造者。
- 将复杂产品的创建步骤分解在不同的方法中，可以更加精细的控制产品的创建过程。
5.2 建造者模式的缺点
- 建造者模式所创建的产品一般具有较多的共同点，产品的组成部分相似，也就是说对象的属性差不多。但是如果产品之间的差异性很大的话，就不适合使用建造者模式，因此其使用范围受到一定的限制，要求还是比较严格的。
- 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得庞大，增加系统的理解难度和运行成本。
假设我们要设计一个复杂的文档编辑器，这个编辑器支持多种文档格式（如HTML、PDF、Markdown等），并且每种格式都有多种不同的配置选项（如字体大小、颜色、布局等）。此外，用户还可以选择不同的输出目标（如屏幕显示、打印、网络发布等），每种输出目标也有不同的要求。对于HTML格式，我们可能需要一个 HtmlBuilder ，对于PDF格式，需要一个 PdfBuilder ，对于Markdown格式，需要一个 MarkdownBuilder 。同时，对于每种输出目标，我们还需要进一步细分。例如，对于屏幕显示的HTML文档，可能需要一个 HtmlScreenBuilder ，对于打印的HTML文档，需要一个 HtmlPrintBuilder ，等等。这样就导致类的数量很多，不好管理。
5.3 建造者模式的适用环境
对象有复杂的内部结构，并且想通过相同的创建过程得到不同的产品，就可以考虑使用建造者模式。
六、结语
“建造者模式把复杂对象的『生产过程』拍成一部电影：Director 做导演，Builder 是剧本，ConcreteBuilder 才是演员，最后 Product 是上映的大片。换一批演员（ConcreteBuilder）就能拍不同风格的续集，而观众（客户端）永远不用知道幕后有多复杂。”
完~