Builder Pattern

Description

The builder design pattern is a creational design pattern that provides a way to construct complex objects step by step. It separates the construction logic from the object’s representation, allowing the same construction process to create different representations.

In Go, the builder pattern is useful in scenarios where the construction of an object involves multiple steps or requires different configurations to be possible during an application’s life cycle. It provides a structured approach to creating objects with varying attributes while keeping the construction process simple and manageable.

When to use

We utilize the builder pattern in the following scenarios:

• Simplify complex object construction: Use the builder pattern when the object constructed is big and requires multiple steps. The construction of the object instance becomes simple, and it does not require a large constructor.

• Create independent versions of a product: Use it when a different version of the same product needs to be created—for example, we want a network client to make API calls to two different dependencies. While the underlying behavior of both would be similar, we might want to set different time-outs or tweak the configs slightly for each dependency. Builder pattern allows us to build custom instances of the same entity as per our requirements.

• Prevent incomplete data submission: The builder pattern is essential when a half-constructed final object should not exist. Either we require a Build function to be called at the end to validate whether all information has been fully and correctly set, or we instantiate with sensible defaults in the first place—for example, let us say we create a data structure for storing information regarding land vehicles. We must never have any instance of this data structure with no wheels, because that would make no sense. However, while building an instance, it is possible we might mistakenly forget to initialize a certain attribute. Having a builder pattern set a predefined default, or necessitate a Build function that validates whether you have set the wheels or not, will be a powerful safeguard for the future.

When not to use

Avoid using the builder pattern in the following scenarios:

• Avoid overcomplication of basic entities: Avoid using when we have a simple object with limited configurability—if the entity has very few fields or doesn’t need any real configurability for different uses, the builder pattern would be completely unnecessary.

• Preserve immutability: Avoid using if the object we’re creating is, or wants to be, immutable. Immutable means its attributes cannot be modified after construction, preventing any potential possible corruption of data. Immutable data is often convenient when dealing with concurrency and thread safety issues. A builder pattern that allows users to customize the object would be a terrible idea here.

Sample code

Let us look at how we would use the builder pattern to implement a functionality to build vehicles.