Understanding Builder Pattern

Jalitha Dewapura
Design Patterns with Java
4 min readMay 27, 2021

The builder pattern is under creational design patterns. As the name implies, it is an alternative way to construct complex objects by dividing them into small pieces. This is a very useful pattern when you have to implement different immutable objects using the same object-building process. In simple words, the object creation process is simplified by a step-by-step approach.

This pattern is used in some situations like the number of properties is high and few properties are initialized in each object.

Let’s take an example to understand these use cases.

Assume we are creating an application for a supermarket. Then we need to implement the product class and each product has few different properties such as,

  • productCode
  • name
  • price
  • manufacturedDate
  • expireDate
  • companyName
  • ingredients

Some items don’t have a manufacture or expiration date. (ex:- books, pens, cups, plates)

Some are don’t have a company name. (ex:- vegetables, fruits)

If it is a natural item, ingredients don’t make any sense. (ex:- rice, vegetables)

As you see, every field has not to be filled. So, if we take all the fields in every object, some fields might be null in each object. There are two different ways to create objects and fill the fields.

  1. Passing all the arguments by the contractor.
  2. Create an instance by default contractor and setting all the fields by setter methods.

Let’s discuss the disadvantages of these two methods.

In the first method, we have to remember the sequence of all parameters. If the field value is not available at the time, we have to pass null.

In the second method, we have setter methods for every field. Therefore, we can change it anytime. But in some situations, we need to keep objects immutable. If we have setter methods, it will violate immutability.

In case you use this type of application, there might have some null values as below. These null values should not be passed into the constructor. You might think, we can use different constructors to overcome this issue. But it will be a mess.

To overcome these disadvantages, the builder pattern introduces step by step approach to create an object. Let’s see how it works.

Product class with inner Builder class,

  1. First, I create an inner class called Builder in the Product class. This builder class should be static. Otherwise, we need to create an instance of the Product class to access this Builder class.
  2. This builder class also has the same properties as the Product class and they should be private.
  3. Then we need to create the constructor for the Builder class. If there are any mandatory properties, we can pass them to the Builder class constructor. (ex:- productCode, name)
  4. Then we need to create methods for each non-mandatory property. These methods return the Builder instance with one property is initialized.
  5. Next, we need to create a constructor for the Product class. It takes a builder instance as an argument and it assigns all properties by the builder instance properties.
  6. Finally, we need to create the build() method inside the Builder class. That method will return a Product instance.

Application class,

Here, we need to create a Builder class instance and then we class call any method inside it. Such as price, manufactureDate, expireDate, ingredients.

Finally, the build method was called to create a Product instance.

Output,

The main disadvantage of this pattern is initial coding part is a little high. But once you implement it is really easy to work. One example of a builder pattern is the StringBuilder class which is an inbuilt class in java.

Here it comes to the end of the article. I hope you understand the builder pattern as well. If I miss any point, let me know in the comment section. Keep in touch. I will post other design patterns as well. Happy Learning !

Reference

[1] Richard Helm, Ralph Johnson, John Vlissides, Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.

--

--