建造者模式又叫做生成器模式，是23种设计模式中的一种创建型模式。建造者模式，顾名思义，就是为创建对象而生的模式。
（一）定义
将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。
如果我们使用了建造者模式，客户端只需要指定具体的建造类型，就可以创建出不同的对象，而每个对象的建造过程以及部件内部的建造细节是对客户端不可见的。也就是说，建造者模式很好的封装了一个对象的构建过程，并且把这个对象的每个组成部分进行了封装。从而可以到达另一个目的-复用。可以发现，建造者模式也是围绕着面向对象封装这一特点进行设计的。
（二）角色
Product：建造者模式中所要生产的产品，即要创建的复杂对象，这个复杂的对象至少由1个部分（部件）组成。
AbstractBuilder：定义了一些抽象接口，以表明产品对象的各个组成成分。这些接口实际上代表了要创建一个复杂的对象需要提供哪些部件（也就是这个复杂对象由哪几部分组成），但并不涉及具体的部件的创建。每个部件具体的创建交由ConcreteBuilder来实现。同一个部件，不同的ConcreteBuilder可以提供不同的实现。
ConcreteBuilder：继承自AbstractBuilder，内部持有一个初始化好的Product实例，实现AbstractBuilder定义的接口，来为这个product实例（即我们需要构建的复杂对象）的构建提供部件。针对不同的业务场景，我们可以对每一个部件提供不一样的实现。 然后把这些构建好的部件（即组成复杂对象的部分）设置给product实例。
Director：调用具体建造者builder来创建复杂对象的各个部件，通常这个builder是作为一个参数从外界传递给director对象的，在director中不涉及产品的具体信息，director只负责操纵builder，来完成复杂对象各个部件的创建或者通过操作builder使复杂对象的各个部件按某种顺序创建。
（三）UML类图
（四）示例代码
/// 产品类
class Product: NSObject {
var parts: [String] = [String]()
/// 添加部件
func add(_ part: String) {
parts.append(part)
}
/// 展示成品
func show() {
for i in 0 ..< parts.count {
print(parts[i])
}
}
}
/// 抽象建造者类
protocol IBuilder {
func buildPartA()
func buildPartB()
func buildPartC()
/// ...
func getResult() -> Product
}
class AbstractBuilder: NSObject, IBuilder {
private var product: Product = Product()
func buildPartA() {
}
func buildPartB() {
}
func buildPartC() {
}
func getResult() -> Product {
return product
}
}
/// 具体建造者类1
class ConcreteBuilder1: AbstractBuilder {
private var product: Product = Product()
override func buildPartA() {
product.add("partA1")
}
override func buildPartB() {
product.add("partB1")
}
override func buildPartC() {
product.add("partC1")
}
override func getResult() -> Product {
return product
}
}
/// 具体建造者类2
class ConcreteBuilder2: AbstractBuilder {
private var product: Product = Product()
override func buildPartA() {
product.add("partA2")
}
override func buildPartB() {
product.add("partB2")
}
override func buildPartC() {
product.add("partC2")
}
override func getResult() -> Product {
return product
}
}
/// 指挥者类
class Director: NSObject {
/// 使用客户端提供的builder创建产品的各个部件
func construct(_ builder: AbstractBuilder) {
builder.buildPartA()
builder.buildPartB()
builder.buildPartC()
}
}
/// 客户端调用
let director = Director()
let builder1 = ConcreteBuilder1()
director.construct(builder1)
let product = builder1.getResult()
product.show()
（五）优点
- 实现了客户端和产品对象创建过程的解耦。因为建造者模式封装了对象的构建过程，使客户端无需感知每个对象的构建细节。所以更加符合面向对象的封装特性，同时也有利于部件的复用。
- 易于扩展，符合开放-封闭原则。因为不同的建造者builder负责生产不同的对象，不同的builder之间毫无影响，所以扩展起来也相当方便，无需修改原有的builder类，只需要增加一个具体的builder类即可，符合开放-封闭原则。
- 细节依赖抽象。将产品本身与产品的创建过程实现了分离(也就是解耦)，产品本身不依赖于创建过程，使同样的创建过程可以创建不同的对象（只是具体每个组件的实现不同）。
（六）缺点
- 因此使用场景受限。建造者模式一般只适用于创建的产品结构相似的场景，即不同的产品具有相同的组成部件，只是组成部件的具体实现不同，所以使用场景有限。
- 建造者模式需要客户端感知的比较多，客户端需要知道director、concreteBuilder以及concreteProduct。可以结合简单工厂模式来优化。
（七）建造者模式 vs 工厂方法模式
- 都遵守开发-封闭原则。建造者模式是一个具体的builder构建一种具体的产品。工厂方法模式是一个具体的factory生产一种具体的产品。这两个模式中，构建产品的类（concreteFactory和ConcreteBuilder）和产品类都是1 : 1的存在。
- 产品种类数量不同。建造者模式通常只有一个产品类，工厂方法模式通常有一个抽象产品类和多个具体产品类。
- 建造者模式不同的产品结构相同（即组成部分相同），细节不同（具体组成部分的实现可能不同）。工厂方法模式不同的产品可能结构和细节都不相同。
- 建造者模式更加侧重于封装对象各个组件的装配顺序。工厂方法模式侧重的是封装对象的创建过程。
（八）应用场景
- 当一个对象的构建过程比较复杂时可以考虑使用建造者模式。
- 当一个对象的构造器存在多个参数（或者可以说由多个子对象组成）时，可以考虑使用建造者模式。
- 建造者模式主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，这个复杂对象通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
用简单工厂改造建造者模式
建造者模式中，客户端不但要认识director类，还要认识builder类，结合简单工厂模式，给director传递一个枚举值，director内部根据枚举值创建对应的builder，并让builder构造复杂对象的各个组成部分，最后把复杂对象返回。这样的好处是，客户端只感知director类和product类，缺点是director中的逻辑变得复杂，且不符合开放-封闭原则。
参考文章
java设计模式之建造者模式
建造者模式（Builder Pattern）- 最易懂的设计模式解析
文／VV木公子（简书作者）
PS:如非特别说明，所有文章均为原创作品，著作权归作者所有，转载请联系作者获得授权，并注明出处。
