Introduction

中文為生成器模式，他的目標是要將複雜類別的結構與實作細節分離，透過相同的結構呈現不同的實作細節。

生成器模式中，運作角色有以下幾個

• 抽象生成器 ( Builder ): 定義建立產品步驟的接口
• 實體生成器 ( Concrete Builder ): 實現建立產品細節的類別
• 產品 ( Product ): 最後使用端想要得到的物件
• 主管 ( Director ): 控制要如何生成產品的類別
• 使用端 ( Client )

使用場景

希望建立不同形式的產品時，且產品間的製造過程相似差異也不大時，即可使用。
當需要建立同一個物件的不同表示方式時，意即當創建具有多個形式的產品時，也可使用。

雛形演練

UML

Builder & ConcreteBuilder

package Directors

import "builder/Products"

type Builder interface {
	/* TODO: add methods */
	Build()
}

type ConcreteBuilder struct {
	result Products.Product
}

func NewConcreteBuilder() ConcreteBuilder {
	return ConcreteBuilder{}
}

func (builder *ConcreteBuilder) Build() {
	builder.result = *Products.NewProduct()
	builder.result.Built = true
}

func (builder *ConcreteBuilder) GetResult() Products.Product {
	return builder.result
}

Director

package Directors

type Director struct {
	builder Builder
}

func NewDirector(builder Builder) *Director {
	return &Director{builder: builder}
}

func (d *Director) Construct() {
	d.builder.Build()
}

Product

package Products

type Product struct {
	Built bool
}

func NewProduct() *Product {
	return &Product{Built: false}
}

main

package main

import (
	"builder/Directors"
	"fmt"
)

func main() {

	builder := Directors.ConcreteBuilder{}
	director := Directors.NewDirector(&builder)
	director.Construct()

	product := builder.GetResult()
	fmt.Println(product)

}

輸出結果優缺點分析

優點

• 在生成器模式中，產品的組成對於使用端來說是不可視的，這樣一來就解除了產品建立邏輯與產品間的耦合
• 每個實體生成器都是相對獨立的物件，因此可以快速且方便的替換掉生成器，無須修改原有的code，符合開放封閉原則 ( Open-Closed Principle, OCP )

缺點

• 此模式侷限於產品間的建立方式需要十分相似，如果差異過大則不是和生成器模式，因此受用群偏小生成器模型主要目的是為了解除產品與建立過程之間的耦合，但當系統一但大起來，產品越來越多樣時，則會增加code的閱讀難度及統維運的成本

Conclusion

Design Pattern

生成器（Builder）模式是一個用於將一個複雜對象的構造與它的表示分離的設計模式。這使得相同的構建過程可以創建不同的表示。模式中包含抽象生成器（Builder）、實體生成器（Concrete Builder）、產品（Product）、主管（Director）和使用端（Client）等角色。