Design Patterns: The Builder Pattern

The second pattern in our series is the builder design pattern. this pattern is a creational design pattern that is used to encapsulate the construction of an object and allow it to be constructed in steps.

In the context of Go programming this pattern helps us construct complex objects without initializing their struct or writing the logic they require. Imagine an object that could have dozens of fields that are more complex struct themselves. If you have many objects with these characteristics implementing the logic they require becomes cumbersome, the builder pattern shines when we need to build composite structures. let's illustrate with an example.

Suppose we have a vehicle factory, vehicles can be of any type, since building the vehicles follow more or less the same process (assemble the structure, place the wheels, and place the seats) we need a director object for managing builders objects. for various vehicle builders and the vehicles objects (Car, Motorbike or Bus). The builder design pattern can be best summarized as the relationship between a director, a few Builders, and the product they build.

In our example the director is represented by the ManufacturingDirectory type that represent the builder class responsible for building vehicle objects. The vehicle can be a Car as well as well as a Motorbike for our example

The first builder is the car builder. It must implement every method defined in the build process interface. This is where the information for that particular builder will be set. Our next builder is the BikeBuilder

The BikeBuilder and the CarBuilder must be the same, as they all are Builder implementations, on have to keep in mind that their method of manufacture differ slightly. In the spirit of test driven development (well sort of..) let's wrte failing tests for our builder types.

We define test cases for both the CarBuilder and the MotorBikeBuilder

If you run these test cases they will fail as we haven't provided concrete implementations for our builders yet. We will start by implementing the ManufacturingDirector type. It must accept a build and construct a vehicle object using the provided builder.

We first start by implementing the methods of our ManufacturingDirector type

Then we implement our first builder the CarBuilder type

The next builder type is the MotorBikeBuilder type, like the CarBuilder, this builder must store an object of type VehicleProduct

Now if you run the test we wrote previously they should all pass!

Pros of the Builder pattern

The builder pattern has few benefits for its use:

• It encapsulates the way a complex object is constructed
• It allows objects to be constructed in a multi-step and varying process (as opposed to one-step factories)
• It hides the internal representation of the product from the client
• Product implementations can be swapped in and out because the client only sees an abstract interface.

The Drawback

• Constructing objects require more domain knowledge from the client.

Conclusion

The builder design pattern help us maintain an unpredictable number of objects by using a common construction algorithm that is implemented by the builder class. The construction process is always abstracted from the user of the product. The builder pattern should be avoided when we are unsure about the stability of the object construction algorithm overtime because any small change in the interface can affect the builders in sometimes backward incompatible ways. In the next article we will tackle another creational design pattern. The Factory pattern.