The Builder Design Pattern in Python is a creational pattern that allows for the construction of complex objects without depending on their representation, separating the process of creating an object from the code that depends on the interface of an object.
Abstract
The Builder Design Pattern in Python is a creational pattern that enables the construction of complex objects without depending on their representation. It separates the process of creating an object from the code that depends on the interface of an object. The pattern is useful when building several types of complex objects or when building complex objects step by step, where the order of the steps may change. The Builder pattern increases code quality and flexibility, but it adds complexity to the code.
Opinions
The Builder pattern is useful when building complex objects step by step, where the order of the steps may change.
The Builder pattern increases code quality and flexibility.
The Builder pattern adds complexity to the code.
The Builder pattern is useful when building several types of complex objects.
The Builder pattern reduces the parameters of the constructor and makes the methods highly readable.
The Builder pattern allows for the creation of complex immutable objects without much complex logic.
The Builder pattern is useful when building trading bots by combining several components.
The Builder pattern is worth the complexity because it increases code quality.
The Builder pattern is better to use for real complex cases with a lot of objects to create.
You can also find all the code used through this series on GitHub.
The Builder pattern is a creational pattern allowing you to build complex objects without depending on the representation of these objects. It means the same Builder can build different objects.
Like most of the creational patterns, it separates the process of creating an object from the code that depends on the interface of an object.
It is used to create objects step by step.
Problems the Abstract Factory can Resolve
Imagine you want to build computers in your app. You want to have several types of computers hard-coded. One way to do this is to make a Computer class and just make subclasses like this:
The problem is you can end up having a lot of classes with very similar code. And imagine one day you want to add a ComputerManual class. You will have to copy-paste a lot of code.
Also, if you want to add new parts to your computers, such as RAM, you will have to modify a lot of code.
One way to avoid that is the Builder pattern.
Solution
The purpose of the Builder pattern is to abstract the construction. So, we’ll start with making a Computer independent from its components.
Then, we can make an abstract Builder which is an interface for all the builders you want to make. In our case, we just have one concrete builder: the computer builder. But if one day we want to add a computer manual builder, it can be easily done by subclassing Builder .
We can implement our concrete builders now. But wait, gaming computers and office computers have parts in common, no? So we can make the ComputerBuilder abstract and hard-code some parts. Then, we can subclass it into 2 concrete builders, defining specific parts.
Once it’s done, we can add a Director . It’s not mandatory, but it can be useful. A Director separates the construction process from the Builder , allowing you to specify different ways to construct objects. For example, perhaps we just want a computer with a case instead of a full-featured computer. The example would be more relevant if we were working with vehicles. A vehicle can have many options, and the Director allows us to build vehicles full-options or without options.
Here is the code:
I use a lot this pattern when building trading bots. Indeed, it allows me to build complex trading bots by combining several components. For example, I have components to write data to a database, use external sources, scrape the web, analyze data, etc… And I can combine these components to build custom trading bots depending on my needs.
Applicability
I guess thanks to the example you know when you should use the Builder pattern, but let’s summarize this here.
You should use the Builder pattern when you have to build several types of complex objects.
You should use the Builder pattern when you have to build complex objects step by step, and the order of the steps may change.
Advantages
You can easily extend your program and add new types or variants of objects without dependencies.
The parameters of the constructor are reduced and the methods are highly readable.
You can build complex immutable objects without much complex logic.
Disadvantages
The Builder pattern adds a lot of lines to the code. But the effort is usually worth it because the design is much more flexible and the code is more readable.
For each product, you have to create a concrete Builder.
Final Note
This pattern can seem a bit complex for what it does, but trust me the complexity is worth it because it increases so much your code quality. Obviously, it’s better to use it for real complex cases with a lot of objects to create.
To explore the other stories of this story, click below!