Builder Design Pattern
A builder pattern should only be used for creating complex objects, like when object creation needs to be separated from its assembly, such as trees.
Our recipe needs the following ingredients:
- Adding a builder interface
This abstract base class defines all of the steps that must be taken in order to correctly create a product. For our example, interface IBuildMobile, - Creating a concrete builder class
These classes contain the functionality to create a particularly complex product. For our example, the class Apple & class OnePlus, - Implementing a director
The director-class controls the algorithm that generates the final product. A director object injects the product through the constructor. The director then calls methods of the concrete builder in the correct order to generate the product. On completion of the process, the GetProduct method of the builder object can be used to return the product. For our example, class Mobile & method which returns the mobile is GetMobile() in our example.
The builder pattern aims to separate the construction of a complex object from its representation so that the same construction process can create different representations.
Now you probably are scratching your head wondering what in the world was that?
Here is what I was trying to convey… The builder pattern removes any and all construction or initialization code from an object class and abstracts it out to an interface.
It is used to construct a complex object step-by-step and the final step will return the object of the final product.
OK! Enough talk! Let’s see how UML would look like for the example which we are going to design.
Let’s have 2 mobile-phone’s implementation: OnePlus & Apple, and have a client to only worry about calling these classes rather than worrying about what is there in mobile and how it supposed to get it.
Now imagine that you have to make the Mobile class’s object. You need to have mobile’s specifications, plus which mobile is what( OnePlus or Apple) & blah blah blah.
Why does the client have to worry about any of that?
Let’s begin with interface IMobileRequirements. It defines all the requirements your mobile is supposed to have.
Now it’s concrete implementation: class MobileRequirements which sets all the basic requirements of mobile.
Now our builder interface: IBuildMobile
A concrete representation of IBuildMobile. Basically our concrete builder classes.
first concrete class OnePlus
second concrete class Apple
Now our final director: class Mobile
Last as usual, but not the least, the caller: class program.
Let’s see the output when the client wants an Apple phone:
and when output when the client wants an Onepplus phone: Note: just uncomment above code and run the application.
Perfect & flawless!
Summary
In this article, we learned
- Where the builder pattern fits into the larger design pattern picture.
- How to create an object class and abstract out its constructor into an interface.
- How to create and configure concrete builder representations.
- The role of the director-class and managing the overall build process.
I hope you’ve come away from this with a real grasp of the builder pattern and how it can be applied to your personal projects in the future.
If you’ve enjoyed the article, which I hope you have, please apply your knowledge to enliven the code in your projects.
Download code from here: https://github.com/RikamCZ/Builder-Design-Pattern
Connect with me:
https://www.linkedin.com/in/rikampalkar/
