Builder Design Pattern

type
Shorts
date
Jan 22, 2025
description
Builder pattern is extremely useful when you wish to incrementally build an object based on different criteria and you wish to keep your object highly configurable.
🚧
This post is for anyone developing a codebase based on the Object-Oriented Paradigm. This post is Language agnostic and the learnings have an implementation across all OOP-based languages.
In the previous post of this Design series, we learned about the Factory Method Design Pattern - What is it? How to use it? When to use it?
In this post, let's look at another Creational Design pattern - Builder Design Pattern.

Introduction

Consider a scenario where you need to build a highly configurable, step by step initialized object. There are a lots of fields to be initialised and a plethora of flags to be set. You could:
  1. Create a big ass constructor with all the parameters and flags.
  1. Set the values manually in your client code using setters.
The Builder pattern exists to solve the exact problem. It allows you to incrementally build an object by invoking certain functions on a Builder class which is then responsible for initialising the object.
 
When there is a requirement to create a highly customisable object whose behavior can be mutated based on a lot of conditions, it is advised to use a builder pattern.

Code Smells

Telescoping Constructors

A class may start accumulating a host of initialisation parameters over time and it becomes harder to initialise over time. Any addition of a parameter has to be accompanied by modifying all the places where the class has been initialised.

Optional Parameters

An extension of Telescoping Constructor issue is Optional parameters. Setting optional parameters in Constructor becomes awkward and cumbersome.

Complex Object Creation

Sometimes a small business logic is required while object creation. Instead of scattering the logic everywhere, the builder can encapsulate the same, allowing it to be reused in multiple places.

Repeat Object Creation with slight variations

Sometimes you need to create objects with slight variations. Using traditional constructors increases code duplicity and reduces maintainability.
🔥
In many scenarios, Builder pattern can be an alternate to creating child classes and derived classes.
notion image

Example

Suppose you need to initialise a Pizza object. The Pizza is highly customisable based on:
  1. Size of Crust.
  1. Cheese types and fillings
  1. Sauces
  1. Toppings
Without Builder:
With Builder:

Actual Builder Code

Director

The Recipe Provider
To put it simply, you can extract a set of calls to a separate Director class. The Director is then responsible to orchestrate the order and steps of the process. It decouples the client code from the construction details, allowing you to reuse the same construction process for a known configuration.

🚫 When not to use a Director?

  • Ad-hoc Construction: If clients need full control over the building process (e.g., custom pizzas with arbitrary toppings), let them use the builder directly.
  • Simple Objects: If the object has few parameters, a director adds unnecessary complexity.

⚖️ Pros & Cons of Builder Pattern

notion image

Conclusion

So, in this post, we discussed an overview of Builder Pattern and how it can be used to create complex objects iteratively and based on our requirements. The steps to building the objects can be further abstracted out into set procedures inside a Director to maintain consistency.
Builder Pattern is a wildly popular pattern used in public SDKs(Eg. Amazon AWS SDKs) which allows for custom initialisation of objects interacting with AWS resources in a variety of manner.
Until next time, ✌🏻…