I. Builder - Creational Pattern

The Builder is a Creational Design Pattern that lets you construct complex objects step by step. Unlike other creational patterns, Builder doesn't require products to have a common interface. This makes it possible to reuse the same construction process to produce different representations of an object.

The pattern addresses the classic problem of telescoping constructors — when a class has too many optional fields, constructors quickly become unmanageable. Builder abstracts the initialization logic away from the caller, while ensuring that every concrete builder follows the same sequence of steps.

II. Real-world Example

Imagine a vehicle manufacturing facility. The factory needs to build different types of vehicles — bicycles and motorbikes — using the same production steps. Each step (setting wheels, seats, and structure) must be executed in a defined sequence, but the outcome differs depending on which builder is active.

This use case introduces the following components:

1. VehicleProduct: The final assembled object. It holds three fields: Wheels (int), Seats (int), and Structure (string).

2. BuildProcess (interface): Defines the construction contract — SetWheels(), SetSeats(), SetStructure(), and GetVehicle(). Each method returns the builder itself, enabling method chaining.

3. BicycleBuilder: A concrete builder that produces a bicycle — 2 wheels, 1 seat, structure "Bicycle".

4. MotorbikeBuilder: A concrete builder that produces a motorbike — 2 wheels, 2 seats, structure "Motorbike".

5. ManufacturingDirector: The orchestrator. It holds a reference to a BuildProcess and calls Construct() to execute all steps in the correct order, regardless of which builder is set.

The class diagram for the above scenario:

III. Implementation

• Definition of the product:

1package builder
2
3type VehicleProduct struct {
4	Wheels    int
5	Seats     int
6	Structure string
7}

• Definition of the BuildProcess interface:

1package builder
2
3type BuildProcess interface {
4	SetWheels() BuildProcess
5	SetSeats() BuildProcess
6	SetStructure() BuildProcess
7	GetVehicle() VehicleProduct
8}

• BicycleBuilder — concrete builder for bicycles:

1package builder
2
3type BicycleBuilder struct {
4	v VehicleProduct
5}
6
7func (c *BicycleBuilder) SetWheels() BuildProcess {
8	c.v.Wheels = 2
9	return c
10}
11func (c *BicycleBuilder) SetSeats() BuildProcess {
12	c.v.Seats = 1
13	return c
14}
15func (c *BicycleBuilder) SetStructure() BuildProcess {
16	c.v.Structure = "Bicycle"
17	return c
18}
19func (c *BicycleBuilder) GetVehicle() VehicleProduct {
20	return c.v
21}

• MotorbikeBuilder — concrete builder for motorbikes:

1package builder
2
3type MotorbikeBuilder struct {
4	v VehicleProduct
5}
6
7func (c *MotorbikeBuilder) SetWheels() BuildProcess {
8	c.v.Wheels = 2
9	return c
10}
11func (c *MotorbikeBuilder) SetSeats() BuildProcess {
12	c.v.Seats = 2
13	return c
14}
15func (c *MotorbikeBuilder) SetStructure() BuildProcess {
16	c.v.Structure = "Motorbike"
17	return c
18}
19func (c *MotorbikeBuilder) GetVehicle() VehicleProduct {
20	return c.v
21}

• ManufacturingDirector — the orchestrator:

1package builder
2
3type ManufacturingDirector struct {
4	builder BuildProcess
5}
6
7func (f *ManufacturingDirector) SetBuilder(b BuildProcess) {
8	f.builder = b
9}
10func (f *ManufacturingDirector) Construct() {
11	f.builder.SetSeats().SetStructure().SetWheels()
12}

• Running the example:

1fmt.Println("*** Example Builder ***")
2manufacturingVehicle := builder.ManufacturingDirector{}
3bicycleBuilder := &builder.BicycleBuilder{}
4
5manufacturingVehicle.SetBuilder(bicycleBuilder)
6manufacturingVehicle.Construct()
7
8bicycle := bicycleBuilder.GetVehicle()
9fmt.Printf("Vehicle is %s has %d wheels, %d seats.\n",
10	bicycle.Structure, bicycle.Wheels, bicycle.Seats)
11fmt.Print("*** End of Builder ***\n\n\n")

With the output:

1*** Example Builder ***
2Vehicle is Bicycle has 2 wheels, 1 seats.
3*** End of Builder ***

IV. Explain the example above

This example demonstrates how the Builder pattern orchestrates step-by-step object construction through a director, decoupling the construction logic from the caller.

1. Setting up the Director and Builder

1manufacturingVehicle := builder.ManufacturingDirector{}
2bicycleBuilder := &builder.BicycleBuilder{}
3manufacturingVehicle.SetBuilder(bicycleBuilder)

• A ManufacturingDirector is created — it doesn't know how to build any specific vehicle.

• A BicycleBuilder is injected via SetBuilder(). The director now delegates all construction steps to this builder.

• The director is decoupled from the product details; it only knows the BuildProcess interface.

2. Constructing the vehicle

manufacturingVehicle.Construct()

Internally, Construct() calls:

f.builder.SetSeats().SetStructure().SetWheels()

Each method mutates the internal VehicleProduct and returns the builder itself (method chaining), so the steps execute fluently in sequence:

3. Retrieving the product

1bicycle := bicycleBuilder.GetVehicle()
2fmt.Printf("Vehicle is %s has %d wheels, %d seats.\n",
3	bicycle.Structure, bicycle.Wheels, bicycle.Seats)

GetVehicle() returns the fully assembled VehicleProduct. The caller retrieves it directly from the builder — not from the director.

Log result:

Vehicle is Bicycle has 2 wheels, 1 seats.

4. Swapping the builder — zero changes to the director

To build a motorbike instead, only the builder needs to change:

1motorbikeBuilder := &builder.MotorbikeBuilder{}
2manufacturingVehicle.SetBuilder(motorbikeBuilder)
3manufacturingVehicle.Construct()
4
5motorbike := motorbikeBuilder.GetVehicle()
6// Vehicle is Motorbike has 2 wheels, 2 seats.

The director calls the exact same Construct() method. The difference is entirely encapsulated inside MotorbikeBuilder — Seats = 2 and Structure = "Motorbike".

Summary

• The Director controls the sequence of steps — it doesn't care what is being built.

• The Builder controls the details of each step — it doesn't care about the order.

• Swapping builders produces a completely different product without touching the director.

• Method chaining makes the construction fluent and readable.

V. Conclusion

The Builder pattern shines when you need to construct objects that require multiple steps, especially when the same process should produce different results. It cleanly separates what to build (the builders) from how to orchestrate the build (the director).

That said, we do not always need the Builder pattern to solve similar problems. If an object only has a few fields, a simple struct literal or constructor function is perfectly sufficient. The most important thing is to choose the solution that best fits your specific context.

Thank you for taking the time to read this article! 😊

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Full source code for Go design patterns: available here.