About Petri Kainulainen

Petri is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

Three Reasons Why I Like the Builder Pattern

There are three ways to create new objects in Java programming language:

  1. The telescoping constructor (anti)pattern
  2. The Javabeans pattern
  3. The builder pattern

I prefer the builder pattern over the other two methods.

Why?

Joshua Bloch described the builder pattern and the benefits of using it in Effective Java. He did an excellent job and I will not repeat these benefits in this blog post.

Instead, I will describe three other reasons why I prefer the builder pattern over the telescoping constructor pattern and the Javabeans pattern.

1. It Helps You to Enforce Better Design

Using either the telescoping constructor pattern or the Javabeans pattern means that the properties of the created object must be created before the actual object is created.

This might or might not be a problem.

If the properties of the created object are fetched by using an external service, it is not a problem. However, if the properties are created in the method which creates the “target” object, it is a problem.

In the latter scenario, the lifecycle of the created objects is often bound to the lifecycle of the “target” object.

If this is the case, the builder pattern can help you use the Domain-driven design (DDD) pattern called the aggregate. Martin Fowler specifies the aggregate pattern as follows:

A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it’s useful to treat the order (together with its line items) as a single aggregate.

The builder pattern can help you to design your code in a such way that your domain model is divided into aggregates. This means that the all objects belonging to the aggregate are created by the aggregate root object (Order) and can be accessed only via the aggregate root object.

This moves the construction relation to the logic to the place where it belongs.

2. It Makes You Think

Writing code in the traditional way is easy because you don’t have to think. All you have to do is write the code which copies information from one place to another. It might take some time to do it, but it isn’t a problem to you because you are on your comfort zone.

Maybe you want to just crunch code without thinking what you are doing.

I am not like that (and you shouldn’t be either).

The builder pattern forces you to think about your objects. To be more specific, it forces you to think about the following things:

  • You have to figure out the mandatory and optional properties of an object.
  • You have to identify the properties which lifecycle is bound to the lifecycle of the created object and design the builder so that it emphasizes this.
  • You have to decide what properties cannot be updated after the object is created (and mark these properties as final).
  • You have to decide what properties can be updated and find the best way to update them.

Finding answers to these questions help you to write better code. I can guarantee that if you take the time to find the answers to these questions, your code will look a lot better than the code written on autopilot.

3. It Helps You to Create Domain-specific Languages

If you use create new objects by using the telescoping constructor pattern or the Javabeans pattern, it is hard to add business meaning to your code. You can try to improve the situation by following these principles:

  • The only way you can add business meaning to constructor arguments is to name the arguments in a proper way. This is difficult to do and even if you get it right, the results aren’t optimal.
  • If you use setters, you can of course name the setter methods in a way which adds business meaning to them. However, how often have you seen setter methods which are named following this principle?

99 times out of a 100 the created objects are just objects without meaning. They hold data. That is all.

When you use the builder pattern, you can create a domain-specific language (DSL) for creating new objects by naming the methods of your builder class. This helps you to add business meaning to the code which creates new objects.

This raises one question: how can I update the properties of my objects?

You can of course be boring and use setter methods for updating the individual properties of your objects. But you can do something totally different as well.

Instead of updating individual properties, you can group these properties into meaningful groups and update the values of these properties in a single method. If you name this method correctly, you can create a DSL for updating the information of existing objects.

It Is Not a Silver Bullet

Blake Caldwell says that the builder pattern is basically a less error prone alternative for constructors. I agree with him.

The first thing which you notice when you start to use the builder pattern is that the code which creates new objects is easier to write and read. However, after some time you might notice other benefits as well. I know that I did.

However, it is important that you understand that the builder pattern is not a silver bullet.

I think that no one should follow a best practice just because it is a best practice. This applies to the builder pattern as well.

If your object has only a few constructor arguments, it makes no sense to use the builder pattern. However, because of the benefits described in this blog post (and in Effective Java), you should consider using the builder pattern every time when you have to create new objects.

Reference: Three Reasons Why I Like the Builder Pattern from our JCG partner Petri Kainulainen at the Petri Kainulainen blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "Three Reasons Why I Like the Builder Pattern"

  1. Aaron says:

    I like the builder pattern for the same reasons. I thought I’d comment as someone I work with recently said “Ugh… I HATE the builder pattern” which I thought was a bit extreme :D

    I posted an example DSL recently, to try to funnel other people to do their string-ey validation via some common mechanism rather than random implementations all over the place.

    I like it, but I’ve not had any feedback yet:

    http://blog.aaronshaw.net/2014/02/03/simple-java-dsl-with-fluent-interface/

Leave a Reply


5 − four =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close