Explain Design Pattern Builder Like I'm Five

So I have to create a lot of big objects for the project I am working on.
Looking for the most appropriate design pattern for my case, I searched the design pattern Builder and found many differents point of view, some contracting others.

Could someone explain the pattern, and what are the pro and cons of the pattern? maybe when to use it and when not? And maybe do you have other patterns that could work for manipulating big classes with more than ten properties?

Thanks a lot, it could really help me in my current work.

Comments

[Kofi Oghenerukevwe H.]

Hey, let me give this a shot.

There are two main use cases for the Builder Design Pattern

1.) The first use case is if you want to build a class object from a separate representation. For instance, you have an xml file or a json file that specifies some properties for your object. In this sort of scenario, you could use a Builder class to take the information from your xml file and turn it into an object of your class.

A practical example of this is say you have a CarShop class and a CarShop.xml file.
In your CarShop.xml file you have something like this that specifies details of the carshop and all the cars contained in that shop:

<root>
  <Carshop name="Carshop Inc." Location="Athens, Greece", Starts="10:00am" Closes="6:00pm">
     <cars>
         <car name="Car Name 1" engine="Some car engine" model="BMW" salePrice="20000"/>
         <car name="Car Name 2" engine="Some car engine 2" model="Toyota" salePrice="20000"/>
         <car name="Car Name 3" engine="Some car engine 3" model="Ford" salePrice="20000"/>
         <car name="Car Name 4" engine="Some car engine 4" model="BMW" salePrice="20000"/>
     </cars>
 </Carshop>
</root>

As shown above, the information in Carshop.xml specifies the properties of your Carshop class. In this scenario you would use a CarshopBuilder class to take the information from Carshop.xml and turn it into a Carshop object.

This introduces some level of flexibility into your program. Because say you have both Carshop.xml and Carshop.json representations of a Carshop, all you'd need to do is create two builders XMLCarshopBuilder and JSONCarshopBuilder. Both builders will work with their respective carshop representations and turn those representations into a Carshop object.

2.) The second use case for the Builder pattern is when you see that there are a lot of things and options required for the construction of your class. So say the constructor for your Carshop class looked something like this:

class Carshop{
  public function __construct(Location $location, 
                              Registration $registration,
                              string $name,
                              array $cars,
                              ...
                              //many other objects required here                          
  )
  {
    //body of constructor function
  }
}

This is PHP code because that's what I'm more familiar with but I hope it translates nicely. Just imagine that the constructor for that class has a very long list of item and option parameters required to create the object.

In this scenario each time you wanted to create a new object of the class, you'd have to pass in all those items and options to the constructor. In this instance You could use a Builder class to help you make objects instead of directly calling the constructor.

So keeping with our Carshop Example. You could have Builder classes that create different types of Carshop objects. So from the example above we see that we are passing a Location object to the constructor. We could have an AthensCarshopBuilder that creates Carshops based in Athens. That way all Carshops built by the AthensCarshopBuilder will have their location set to Athens by the builder. Generally you'd use a builder class in this scenario to create objects of a class with specific configuration options.

Personally, I think this second use case of the Builder pattern might be an indicator that your class is doing too much and you should consider breaking it down.

You could also use the Builder pattern for classes with small amount of constructor arguments... it all just depends on what you're trying accomplish at the end of the day. You have to decide if it's easier for you to have a builder class that builds objects with specified configurations or if you'd rather create your objects and pass in the configurations by yourself every time.

[AxelleDRouge]

Interesting, in fact, I am in some way in both case. I have an API that send JSON, with many properties (like 12 properties or more) that I must convert to an object. The results will have to be manipulate to send back another object (in a different form). So both use case can happen.
But what about the critics that I read many times, about the fact that adding all those class makes the code less efficient? a waste of resources, some says ?

[Kofi Oghenerukevwe H.]

I haven't done much research on the criticisms of the builder pattern. But I am interested in exploring the arguments presented by these critics. I'd appreciate it if you shared an article or video link with me that discusses in detail the critics presented on this pattern so I can read these criticisms and make up my own mind.

That said, at least on the surface, I don't see how the use of the builder pattern could be a waste of resources or ... a way of making code less efficient. At least, if you're speaking in terms of the performance of your application. I don't think the use of the builder pattern or any other pattern in structuring your code could affect the speed of your code in any way that is significant if your code is running on modern technology.

The only criticism I can think of, that in my opinion, would be valid right off the bat, is if you're overusing the builder pattern or making use of builders in scenarios that really don't require it. Because it does include an extra layer of complexity.

By extra layer of complexity I mean... when someone is reading through your code, if they come to a point where an object is being created by your builder, they'd have to take the time to understand both the Builder class and the main class i.e both AthensCarshopBuilder and Carshop.

In the absence of the builder class, the only thing they'd have to bother about understanding would be the Carshop class. So the fact that a developer going through your code would need to understand 2 things instead of 1 thing in order to get something done (like make a modification to your Carshop class), is an added complexity. This increased complexity will make it harder for someone else... even perhaps yourself a few months later, to understand and work with your code. The harder the code is to understand, the harder it is to get things done in it... so at least, in terms of developer productivity, I think the overuse of the builder pattern, or frankly, any code design pattern at all, can be a disadvantage.

But like I said, if you have links to other arguments on this issue, I'd like to read through them and share my thoughts on them.

[AxelleDRouge]

You can read some in the comments of that article :

4 Dangerous Problems in JavaScript Easily Solved by The Builder Design Pattern

jsmanifest ・ Nov 25 ・ 12 min read

#javascript #node #webdev

and in the comments of this one :

Builder Design Pattern

Nishan Pantha ・ May 28 '17 ・ 2 min read

#programming #designpatterns

This article on Kotlin :

Avoiding the Builder Design Pattern in Kotlin

Christian Vasquez ・ Jan 5 '18 ・ 3 min read

#kotlin #designpatterns #antipatterns #builder

One for Java :

When Builder is anti-pattern

Sergiy Yevtushenko ・ Nov 5 ・ 2 min read

#java #lang

With so many different point of view, it can get confusing.

[Bijay Kumar Pun]

Since you said ELI5, here you go.
Imagine you are a wizard who builds a wide variety of potions using even a wider variety of ingredients.
One way you can make such potion is by using a class with as many constructor as the number of potion.
Eg: A constructor to make a potion with 3 ingredients will look like this:
MyIngredient(Ingredient1 ing, Ingredient2 ing2, Ingredient3 ing3);
Problem with it is you you need many constructors, and you can not swap places with ingredient; like what if you want to put ingredient2 first and then ingredient1.
This can be solved with Builder Pattern.
With builder pattern you can add as many ingredient as you want and in any possible combination.
So use builder pattern when you are building object with many properties, and the properties are not mandatory.

[AxelleDRouge]

Thanks for the explanation, it's really clear.
And it confirms that this design correspond well to my situation.

my inner Harry Potter fan approves ;)