Design Patterns: The Builder Pattern in Java

Tram Ho

Hello everyone, in this article I will start getting into the first design pattern, which is the Builder Pattern. Builder pattern is a pattern in the Creational Pattern. However, I will try to keep the examples as simple and accessible as possible, prioritizing practical implementations over confusing examples.


For this example, we will pretend that we are part of the Java team working on software for a bank. We will need a way to represent a bank account. This will be our class

We can create it as simple as:

Unfortunately, the solutions are rarely that simple. A new request has appeared that says we track the monthly interest applied to each account, the date the account was opened and, optionally, the branch on which it was opened. So we give version 2.0 of the class BankAccount.

Thanks to new and improved account processing, we have acquired a number of new clients.

If we had 10 different parameters, it would be very difficult to determine what’s in the constructor at a glance. To make it worse, some of them might be optional, meaning we’ll need to create a bunch of overloaded constructors to deal with all possible combinations or them. We’ll have to pass null to our constructor (which sucks!).

You might think that we can mitigate the problem by calling a no-arg constructor and then setting up the account via setter methods. However, that leaves us open to another problem – what if a developer forgets to call a particular setter method? We could end up with an object that is only partially initialized and again, the compiler won’t have any problems with it.

Therefore, there are two specific problems that we need to solve: 1. Too many constructor arguments. 2.The object state is incorrect. This is where the Builder pattern comes into play.

The Pattern

The builder pattern allows us to write easy-to-read, easy-to-understand code for constructing complex objects. It is usually deployed with a good-looking interface, which you may have seen in tools like Apache Camel or Hamcrest. Class builder will contain all the fields that exist on the class BankAccount itself. We’ll configure all the fields we want on the builder class and then we’ll use the builder class to create the account. At the same time, we will remove the public constructor constructor from the BankAccount class and replace it with a separate constructor so that accounts can only be created via the builder class.

It looks like this.

Now we can create a new account as follows.

Is this code more verbose? It’s correct. Is it clearer? It’s correct. Is it better? Since a large portion of our time is spent reading code rather than writing it, I’m pretty sure it does.


We worked through an example where the code started getting simple, and then became more complex. We then use the Builder pattern to solve the problems we discovered.

If you find yourself in a situation of continuing to add new parameters to a constructor, resulting in code becoming error-prone and difficult to read, then maybe it’s a good time to take a step back and consider refactoring the code. builder pattern to use.


Share the news now

Source : Viblo