Builder Pattern – Creational

2018-06-08

In this post, I’d like to talk about the Builder Pattern. This pattern is part of the Creational grouping in which other patterns such as Factory and Singleton are also a part of.

For what do we use the Builder Pattern?

Sometimes we might need to have objects that work in the same way, however, have different components internally. Or we might just need two objects that are similarly built, but of course not the same. For those situations, we can make use of the Builder Pattern.

The Builder does get rid of cases such as an explosion of subclasses to deal with the different configurations that an object can have; cases where classes have a big amount of constructors or cases where a class has a constructor with many parameters to try to deal with all possible configurations.

Most important of all the Builder pattern separates the (maybe complex) construction of an object, from the representation of this object.

Structure

Here I’d like to define two ways that this is encountered: the formal way and another way that you see used quite a lot and in my opinion, it is slightly different than the formal definition.

Formal Structure

Here is the basic structure of the Builder Pattern (if you need a refresher on UML check this post and this post) in the way it is defined in the GoF Patterns Book:

Builder

The Builder is the interface which will define which defines the parts that the constructor accepts

Concrete Builder

This is the implementation of the builder interface. It will assemble the object accordingly to how it defines the object to be implemented

Director

It is simply the class that makes the use of the Builder in order to construct and get the object.

Product

The final object which the Builder is tasked to build.

Example Scenario

Let us use the scenario where we want to build a car. Now a car has the same structure: it has wheels, a transmission, a chassis, a motor, doors, etc. However, each of those components can vary itself in different ways. This is where the builder pattern shines!

If we make use of the SportCarBuilder variant or the RegularCarBuilder variant we are in both cases getting a Car out of the builder!

Implementation

In this example, I won’t define all subtypes used in the code, but just the main parts.

And finally, we can use the code we wrote. By passing a type to the Director.construct() method.

“Out in the Wild” Structure

Here is the basic structure of the Builder Pattern that you might come across while you work on your daily job or favorite open source code. They are quite similar, however, I find it nice to have an extra example:

Builder

The Builder is the class that takes care of building the product object correctly and eventually returning it to the requester class.

You often see this class as an inner class from the Product Class itself, however, this is not a nice clean code approach. One should aim for 1 Class = 1 File.

Director

Just like the former case, this is simply the class that makes the use of the Builder in order to construct and get the object.

Product

The final object which the Builder is tasked to build.

Example Scenario

The scenario will be exactly the same as the above scenario but you will see the differences are in the code:

Implementation

First, we have the Builder itself which is not an interface and it will return a reference of itself so to allow the use of concatenation. It also makes use of the Fluent pattern which makes the code read more like a normal sentence.

Note that we have the method call build() which order the builder to do what is supposed to do if its named “builder”. It passes itself to the car builder and with that avoids long lists of parameters.

All the fields are also package-private which will make sense since the Car constructor will want to access these.

Now before a quick word about the Car object, let us show how the Director gets when we use the structure above instead the formal one:

Finally the car object. In this case, we can have the constructor set to something like package-private since it should only get accessed by the Builder. It also will get a builder and it unpacks on to its variables: