Builder Design Pattern
Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code.
The intent of the Builder design pattern is to separate the construction of a complex object from its representation. By doing so, the same construction process can create different representations.
The builder pattern is a design pattern designed to provide a flexible solution to various object creation problems in object-oriented programming. The intent of the Builder design pattern is to separate the construction of a complex object from its representation. It is one of the Gang of Four design patterns.
What is Builder?
The Builder design pattern describe how to solve recurring design problems in object-oriented software.
The Builder design pattern solves problems like:
- How can a class (the same construction process) create different representations of a complex object?
- How can a class that includes creating a complex object be simplified?
Creating and assembling the parts of a complex object directly within a class is inflexible. It commits the class to creating a particular representation of the complex object and makes it impossible to change the representation later independently from (without having to change) the class.
The Builder design pattern describes how to solve such problems:
- Encapsulate creating and assembling the parts of a complex object in a separate Builder object.
- A class delegates object creation to a Builder object instead of creating the objects directly.
A class (the same construction process) can delegate to different Builder objects to create different representations of a complex object.
Rules
- Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.
- Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
- Builder often builds a Composite.
- Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
Problem : Users
imagine our software has a different type of user such as : employee , manager and has another type wishlist.
class Person {
constructor(name , is_employee = false , is_manager = false , wishlist = []){
this.name = name
this.is_employee = is_employee
this.is_manager = is_manager
this.wishlist = wishlist } do_something(){}}
john = new Person("John" , true , false , ["travel" , "yoga"])
maria = new Person("Maria" , false , true )
Person class has different optional arguments and in the complex application it might be confusing for other developers. if we have another types (is_writer , is_customer etc) Instantiating of Person class contains many true and false arguments.
Solution
Create a PersonBuilder class to build new person and then our builder class return the Person we want:
class Person {
constructor(builder){
this.name = builder.name
this.is_employee = builder.is_employee
this.is_manager = builder.is_manager
this.wishlist = builder.wishlist
} do_something(){}
}class PersonBuilder {
constructor(name){
this.name = name
// by default these parameter are:
this.is_employee = false
this.is_manager = false
this.wishlist = [] }
makeEmployee() {
this.is_employee = true
return this
}
makeManager() {
this.is_manager = true
return this
}
makeWishList(wishlist){
this.wishlist = wishlist
return this
}
build(){
return new Person(this)
}
}john = new PersonBuilder("John")
.makeManager()
.makeWishList(["travel" , "yoga"])
.build()maria = new PersonBuilder("Maria")
.makeManager(true)
.build()
Pros
You can construct objects step-by-step, defer construction steps or run steps recursively.
Allows you to vary a product’s internal representation.
Encapsulates code for construction and representation.
Provides control over steps of construction process.
You can reuse the same construction code when building various representations of products.
Single Responsibility Principle. You can isolate complex construction code from the business logic of the product.
Cons
The overall complexity of the code increases since the pattern requires creating multiple new classes.
