I. Builder – Creational Patterns.
- More generally, the Builder was born to:
reusing an algorithm to create many implementations of an interface. This Design Pattern helps us to construct complex objects without directly instantiating the structure or immediately implementing the logic required by the object. - Imagine we have a complex object with dozens of fields/methods inside, and a few other objects that have just as many fields/methods. It would be difficult to implement all the constructors for those objects, and at the time of development, we have absolutely no idea how many types of objects can be created. Then the Builder Pattern will help us.
II. When to use Builder
- I will give a specific case so you can easily imagine. To create bicycles and motorcycles, one has to go through a lot of stages such as building the frame, building the wheels, building the seat… Here we can fully take advantage of the previously defined steps. for bicycles, without having to redefine the whole thing for motorcycles
- Going back to the definition, the Builder design pattern tries to adapt the following:
- Abstracting complex object initializations
- Create an object
step by step, that is, the first time it is initialized, the object will definitely not be complete, we can customize it bybuildfields/properties to it. - Reuse initialization stages from separate objects
III. Practical examples
Continuing with the example above, I will create 1 object is Vehicle builder and a single object is ManufacturingDirector with the function to receive builders (Bicycle or Motorbike) and constructs products. With the following principles:
- We have manufacturing type to define the structure of what Vehicle needs
- When using the bicycle builder, a
VehicleProductobject consisting of 2 wheels, 1 seat, and 1 structure field with typeBicyclewill be returned. - When using motorbike builder,
VehicleProductobject consisting of 2 wheels, 2 seats, 1 structure field with typeMotorbikeis returned. - The
VehicleProductobject created from theBuild Processbuilder must always be open to modifications.
IV. Implementation
- We first define the VehicleProduct struct, which includes the Wheels, Seats, and Structure properties:
1 2 3 4 5 6 7 8 9 | // vehicle_product.go package builder type VehicleProduct struct { Wheels int Seats int Structure string } |
- Next, to create a Vehicle, we need to define a common process, here we create:
1 2 3 4 5 6 7 8 9 10 | // build_process.go package builder type BuildProcess interface { SetWheels() BuildProcess SetSeats() BuildProcess SetStructure() BuildProcess GetVehicle() VehicleProduct } |
- BuildProcess includes methods SetWheels, SetSeats, SetStructure, these methods represent the work to be done to build a Vehicle, note that the return type of these methods is always BuildProcess. In addition there is
GetVehicle, simply to get Vehicle information only. - Next is BicycleBuilder
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | // bicycle_builder.go package builder type BicycleBuilder struct { v VehicleProduct } func (c *BicycleBuilder) SetWheels() BuildProcess { c.v.Wheels = 2 return c } func (c *BicycleBuilder) SetSeats() BuildProcess { c.v.Seats = 1 return c } func (c *BicycleBuilder) SetStructure() BuildProcess { c.v.Structure = "Bicycle" return c } func (c *BicycleBuilder) GetVehicle() VehicleProduct { return c.v } |
- and MotorbikeBuilder
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | // motorbike_builder.go package builder type MotorbikeBuilder struct { v VehicleProduct } func (c *MotorbikeBuilder) SetWheels() BuildProcess { c.v.Wheels = 2 return c } func (c *MotorbikeBuilder) SetSeats() BuildProcess { c.v.Seats = 2 return c } func (c *MotorbikeBuilder) SetStructure() BuildProcess { c.v.Structure = "Motorbike" return c } func (c *MotorbikeBuilder) GetVehicle() VehicleProduct { return c.v } |
- Next, like the example shown in the previous section, we define a
ManufacturingDirectorobject, which is responsible for taking in a Vehicle Builder and constructing the common steps to construct the most basic Vehicle:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // manufacturing_director.go package builder type ManufacturingDirector struct { builder BuildProcess } func (f *ManufacturingDirector) SetBuilder(b BuildProcess) { f.builder = b } func (f *ManufacturingDirector) Construct() { f.builder.SetSeats().SetStructure().SetWheels() } |
- Run it:
1 2 3 4 5 6 7 8 9 10 | // main.go manufacturingVehicle := builder.ManufacturingDirector{} bicycleBuilder := &builder.BicycleBuilder{} manufacturingVehicle.SetBuilder(bicycleBuilder) manufacturingVehicle.Construct() bicycle := bicycleBuilder.GetVehicle() fmt.Printf("Vehicle is %s has %d wheels, %d seats.", bicycle.Structure, bicycle.Wheels, bicycle.Seats) |
- Result:
V. Conclusion
- The Builder Pattern still gives us good control no matter how many Vehicle types are spawned later. The construction process is always abstracted to the user, the user will not know the complex logic when instantiating a Vehicle.
- Moreover, defining a clear structure will help developers to strictly follow the steps/processes defined earlier in
BuildProcess
Thank you for reading ^^
Source code: https://github.com/khaaleoo/golang-design-patterns
BECAUSE. References
- Go Design Patterns (Mario Castro Contreras)