Skip to content

Creational Design Pattern: Builder Pattern

Builder pattern fixes few problems that factory or abstract factory pattern has. In previous examples of Factory Patterns we only checked concrete objects that only required an empty constructor but what if there are too many parameters and many of them are variable. This makes using factory or abstract factory difficult because of the huge constructor declarations and dependencies that must be resolved in the perfect order.

But Builder pattern tries to solve this problem by providing a way to create a composite object. There are two ways to implement a builder pattern, one is to create an object first and then keep adding parameters and other is to keep the parameters within the builder and initialize the object at once. Builder pattern helps in creating immutable objects. Let’s see an abstract example on the builder pattern and then we’ll see a complete practical example on this pattern.


There are three components in the entire logic, first a composite object that needs to be created, this pattern is better suited for objects that have many attributes that they depends upon. Second a builder inner class that will actually build the object and third a client side that will build the object using the pattern.

First we’ll try to use a way from which we can implement a builder that will work with partial objects and returns the object when actual build method is called. For this we would require two parts one an Object creation with Builder pattern and one client code that will utilize the code.

Above we have an object class named “SomeClass”, this class will use “SomeClassBuilder” to build the object for some class. The client will need to use the builder inner class to create and use the immutable object.
Finally, here’s the usage logic in the client class.

We have used method chaining to chain the call to add attributes. It can also be seen that order of attribute addition does not matter in builder pattern case which is an advantage over constructor based solution. The final object of the Object Class will only be passed to the client when client calls the build() method.

Practical Example

Now we’ll see a more practical example of the Builder pattern with a little twist. This time we’ll do the lazy creation of the object. This promotes immutability as even Builder will never mutate the object but the down side will be that we won’t be able to get rid of Constructor use within the builder. So our logic will work like normal but the client side will have the builder pattern for a better immutable object. Also if user never went ahead with build method call, this will make sure that actual object will never be created which is yet another advantage. Lastly this example will also show what to do, if at least one or two attributes are a must to create the example.

In this example, let’s try to create a class that will build and return a Full Name of a person.

In the above sample, Full name must include first and last name of the person, so they are directly passed to the builder constructor. This way at least these two items are there always, then client can keep on adding other attributes as deems fit. The build() method will create the object in one go.
The only thing left is to see the client code.

Advantages of Builder Pattern

  1. It provides a clear separation between the construction and representation of an object.
  2. It providers a better control over construction process.
  3. It supports to change the internal representation of objects.

Disadvantages of Builder Pattern

  1. Not good when object is for some reason mutable.
  2. Adds quite a bit of overhead or boiler code when there are relatively few number of attributes that can be altered.

Well this is it for the Builder Pattern.
As always thanks for reading.

Published inDesign Patterns

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *