浅析建造者模式

---

0. 前言

建造者模式是创建型设计模式的一种。本篇文章将介绍什么是建造者模式，以及什么时候用建造者模式，同时给出 Kubernetes:kubectl 中类似建造者模式的示例以加深理解。

1. 建造者模式

1.1 从工厂函数说起

试想构建房子类，其属性如下：

type house struct {
	window   int
	door     int
	bed      int
	desk     int
	deskLamp int
}

其中，door, window 和 bed 是必须配置，desk 和 deskLamp 是可选配置，且 desk 和 deskLamp 是配套配置。

通过工厂函数创建 house 对象：

func NewHouse(window, door, bed, desk, deskLamp int) *house {
	return &house{
		window:   window,
		door:     door,
		bed:      bed,
		desk:     desk,
		deskLamp: deskLamp,
	}
}

这里有个问题在于 desk 和 deskLamp 是可选配置。通过 NewHouse 创建对象需要指定 desk 和 deskLamp：

house := NewHouse(2, 1, 1, 0, 0)

这对调用者来说不必要。

继续，使用 set 结合工厂函数构造 house 对象：

func NewHouse(window, door, bed int) *house {
    return &house{
        window:     window,
        door:       door,
        bed:        bed，
    }
}

func (h *house) SetDesk(desk int) {
    h.desk = desk
}

func (h *house) SetDeskLamp(deskLamp int) {
    h.deskLamp = deskLamp
}

创建 house 对象：

house := NewHouse(2, 1, 1)

// 使用 set 设置 desk 和 deskLamp
house.SetDesk(1)
house.SetDeskLamp(1)

看起来还不错。

不过 desk 和 deskLamp 要配套出现，这里并没有检查配套的逻辑。并且，window, door 和 bed 需要检测，如果传入的是 0 或 负数，应该要报错。

结合这两点，继续构建 house 对象。构建有两种思路：思路一，在构造完的 house 对象上添加 validation 方法校验属性。思路二，在工厂函数内校验必配属性，新建方法检查 desk 和 deskLamp 是否配套出现。

这两种思路虽然能实现校验功能，但是都有瑕疵。
思路一，在构造完对象后才验证，如果对象忘了调用 validation，那这个对象就是个不安全的对象。
思路二，校验分开了，对象的属性应该放在一起校验，试想如果参数过多，且相互有依赖关系，那又得新增方法判断，麻烦且容易出错。

并且，对于调用方来说，构造过程暴露太多了。工厂函数的优势在于调用方无感知，如果暴露太多 set 方法，并且由调用方来调用验证方法验证对象属性。那工厂函数的优势将大打折扣。

1.2 工厂函数到建造者的优雅过渡

如何适配上述场景，使得调用方无感知呢？

试拆分上述代码如下：

func NewHouse() *house {
	return &house{}
}

func (h *house) SetRequisite(window, door, bed int) *house {
	h.window = window
	h.door = door
	h.bed = bed

	return h
}

func (h *house) SetDesk(desk int) *house {
	h.desk = desk
	return h
}

func (h *house) SetDeskLamp(deskLamp int) *house {
	h.deskLamp = deskLamp
	return h
}

func (h *house) Validation() (*house, error) {
	if h.window <= 0 || h.door <= 0 || h.bed <= 0 {
		return nil, errors.New("invalid [window|door|bed]")
	}

	if h.desk < 0 || h.deskLamp < 0 {
		return nil, errors.New("invalid [desk|deskLamp]")
	}

	if !(h.desk > 0 && h.deskLamp > 0) {
		return nil, errors.New("need desk and deskLamp at same time")
	}

	return h, nil
}

创建 house 对象：

house, _ := NewHouse().SetRequisite(2, 1, 1).SetDesk(1).SetDeskLamp(1).Validation()

嗯，看起来清晰了不少。不过我们细细分析下逻辑的话还是会发现那么一点怪异的点。这一点在于，house 对象是 set 的主体，这在逻辑上好像不通。

是的，我们需要引入一个新对象叫 Builder 来创建 house，而不是让 house 自己创建自己。

改造代码如下：
示例 1.1

type Builder struct {
	house
}

func NewBuilder() *Builder {
	return &Builder{}
}

func (b *Builder) SetRequisite(window, door, bed int) *Builder {
	b.window = window
	b.door = door
	b.bed = bed
	return b
}

func (b *Builder) SetDesk(desk int) *Builder {
	b.desk = desk
	return b
}

func (b *Builder) SetDeskLamp(deskLamp int) *Builder {
	b.deskLamp = deskLamp
	return b
}

func (b *Builder) build() (*house, error) {
	if b.window <= 0 || b.door <= 0 || b.bed <= 0 {
		return nil, errors.New("invalid [window|door|bed]")
	}

	if b.desk < 0 || b.deskLamp < 0 {
		return nil, errors.New("invalid [desk|deskLamp]")
	}

	if !(b.desk > 0 && b.deskLamp > 0) {
		return nil, errors.New("need desk and deskLamp at same time")
	}

	return &b.house, nil
}

这里做了几点改动：
1）新建 Builder 对象，通过 Builder 对象创建 house。并且，将 house 作为 Builder 的属性，house 是 Builder 造的，作为属性挺合理的。
2）重命名 Validation 为 build，之所以这么命名是想说明 build 是创建的最后一步，结束 build 之后即可获得 house 对象。

对于调用方，创建对象就变成了：

house, _ := NewBuilder().SetRequisite(2, 1, 1).SetDesk(1).SetDeskLamp(1).build()

这里 desk 和 deskLamp 是配套使用的，如果不需要的话。创建对象就变成：

house, _ := NewBuilder().SetRequisite(2, 1, 1).build()

要留意这种结构，它是顺序不一致的。
如果顺序一致的情况，即创建的流程都是一样的。那么可以将 build 抽象为接口，使用不同的接口创建产品，且创建的产品流程是一样的，可以用封装将这一过程封装起来。

举例，使用两个 Builder 创建房子。villaBuilder 先建十个门，再建五十个窗，最后放五十把椅子。residenceBuilder 负责建两个门，两个窗，以及五把椅子。代码如下：

type Builder interface {
	createDoor() Builder
	createWindow() Builder
	createChair() Builder
	build() (*house, error)
}

type villaBuilder struct {
	house
}

type residenceBuilder struct {
	house
}

type house struct {
	door   int
	window int
	chair  int
}

func (vb *villaBuilder) createDoor() Builder {
	vb.door = 10
	return vb
}

func (vb *villaBuilder) createWindow() Builder {
	vb.window = 50
	return vb
}

func (vb *villaBuilder) createChair() Builder {
	vb.chair = 50
	return vb
}

func (vb *villaBuilder) validation() error {
	return nil
}

func (vb *villaBuilder) build() (*house, error) {
	// validate property of object houseBuilder, skip...
	err := vb.validation()

	vb.createDoor()
	vb.createWindow()
	vb.createChair()

	return &vb.house, err
}

func (rb *residenceBuilder) createDoor() Builder {
	rb.door = 2
	return rb
}

func (rb *residenceBuilder) createWindow() Builder {
	rb.window = 2
	return rb
}

func (rb *residenceBuilder) createChair() Builder {
	rb.chair = 1
	return rb
}

func (rb *residenceBuilder) validation() error {
	return nil
}

func (rb *residenceBuilder) build() (*house, error) {
	// validate property of object carBuilder, skip...
	err := rb.validation()

	rb.createDoor()
	rb.createWindow()
	rb.createChair()

	return &rb.house, err
}

func NewBuilder(typ string) Builder {
	switch typ {
	case "villa":
		return &villaBuilder{}
	case "residence":
		return &residenceBuilder{}
	default:
		return nil
	}
}

最后，通过不同类型的 Builder 创建房子：

house, err := NewBuilder("villa").build()

可以看到，通过 Builder 的 build 方法实现了创建过程的封装，对于调用方来说相当友好。

继续往下分析，刚才的参数是固定的。如果要用户可配，而不是内定的参数。怎么做呢？

重新改造代码如下：

type villaBuilder struct {
    house
    window int
    door int
    chair int
}

func (hb *villaBuilder) createDoor(door int) Builder {
    hb.house.door = door
    return hb
}

func (hb *villaBuilder) createWindow(window int) Builder {
    hb.house.window = window
    return hb
}

func (hb *villaBuilder) createChair(chair int) Builder {
    hb.house.chair = chair
    return hb
}

func (hb *villaBuilder) build() (*house, error) {
    // validate property of object villaBuilder, skip...
    err := hb.validate()

    hb.createDoor(hb.door)
    hb.createWindwo(hb.window)
    hb.createChair(hb.chair)

    return hb.car, err
}

func NewBuilder(typ string) Builder {
	switch typ {
	case "villa":
		return &villaBuilder{}
	case "residence":
		return &residenceBuilder{}
	default:
		return nil
	}
}

调用方创建 house：

house, err := NewBuilder("house", 2, 2, 2).build()

这里最大的改变在于 Builder 对象中新增可配置属性 window, door 和 chair。通过 Builer 内的属性将参数传给内嵌产品对象，实现有序创建。

参数可配带来的问题在于，可以整合 villaBuilder 和 residenceBuilder 为一个 Builder。通过该 Builder 实现根据不同配置创建 house。
那就蜕化为前面的 示例 1.1 的实现了。

试想，这时候在新增冰箱和饮料两个属性，且这两个属性是可选的，配套的。那么怎么创建 house 和 car 呢？

同样的道理，将可选项赋值给 Builder 中的属性。代码如下：
示例 1.2

type villaBuilder struct {
    house
    window int
    door int
    chair int
    icer int
    drink int
}

func (vb *villaBuilder) createIcer() Builder {
    vb.house.icer = vb.icer
    return vb 
}

func (vb *villaBuilder) createDrink() Builder {
    vb.house.drink = vb.drink
    return vb
}

func (vb *villaBuilder) setIcer(icer int) Builder {
    vb.icer = icer
    return vb
}

func (hb villaBuilder) setDrink(drink int) Builder {
    vb.drink = drink
    return vb
}

调用方创建过程为：

house, err := NewBuilder("house", 2, 2, 2).setIcer(1).setDrink(1).build()

调用方一直在和 Builder 打交道。可选配置传递给 Builder，最后通过 build 创建出 house，做到了表达和实现分离。

1.3 建造者模式

讲到这里基本也差不多了，在建造者模式中还有个 Director 对象作为更上层的封装。

从上面代码示例中，Builder 负责整体的顺序创建，可以把这块逻辑向上提给 Director，Builder 只关心部件的创建，而不需要关心整体。做到逻辑的进一步拆分。代码示例如下：

type Director struct {
    builder Builder
}

func (d *Director) createHouse() (*house, error) {
    if err := d.builder.validation(); err != nil {
        return nil, err
    }

    d.builder.createDoor()
    d.builder.createWindwo()
    d.builder.createChair()

    return *hb.house, nil
}

调用方只需要创建 Builder 和 Director 而不需要关心实现细节。

画建造者模式的 UML 图，最后感受下：

1.4 建造者模式在 Kubernetes：kubectl 的应用

在 kubectl 上找到了建造者模式的应用，虽然不是“完全体”，不过没有关系。代码如下：

// https://github.com/kubernetes/kubectl/blob/master/pkg/cmd/get/get.go

r := f.NewBuilder().
    Unstructured().
    NamespaceParam(o.Namespace).DefaultNamespace().AllNamespaces(o.AllNamespaces).
    FilenameParam(o.ExplicitNamespace, &o.FilenameOptions).
    LabelSelectorParam(o.LabelSelector).
    FieldSelectorParam(o.FieldSelector).
    Subresource(o.Subresource).
    RequestChunksOf(chunkSize).
    ResourceTypeOrNameArgs(true, args...).
    ContinueOnError().
    Latest().
    Flatten().
    TransformRequests(o.transformRequests).
    Do()

这段代码是不是和我们的示例 1.2 非常像。通过 factory 的 NewBuilder 创建 Builder，接着通过一系列建造者方法构造 Builder，最后构建完成的 Builder 调用 Do 方法创建 resouce.Result 对象。

2. 小结

从上述分析可以做个建造者模式的小结：
1） 建造者模式是表达和实现分离，对于调用方来说不需要关注细节实现。
2） 建造者模式其内部对象建造顺序是稳定的，实现是复杂的。摘录《设计模式之美》的一段话表明什么时候该用建造者模式：

顾客走进一家餐馆点餐，我们利用工厂模式，根据顾客不同的选择，制作不同的食物，如比萨、汉堡和沙拉等。对于比萨，顾客又有各种配料可以选择，如奶酪、西红柿和培根等。我们通过建造者模式，根据顾客选择的不同配料，制作不同口味的比萨。  

3） 建造者模式建造的对象是可用的，安全的。

---