Builder
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Last updated
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Last updated
The Builder is a design pattern that belongs to the Creational Pattern group - the design patterns for object creation of the Builder class
The Builder Pattern is a design pattern used to provide a flexible solution to object creation problems ( object) is different in object-oriented programming.
Allows you to build complex objects using simple objects and using a step-by-step approach. The Builder Pattern also allows you to create different instances of an object using the same constructor code.
Components in the model:
Builder: The Builder interface declares product construction steps common to all types of builders. Abstract interface to create product objects ( object product )
Concrete Builder: provides different implementations of construction steps for the Builder. Concrete builders can create products that don't follow a common interface.
ConcreBuilder: is an object that can build other objects. Build and assemble parts to build objects.
Products: are result objects. Products created by different builders do not necessarily belong to the same class hierarchy or interface.
Director: The Director class defines the order in which the construction steps are called, so you can create and reuse product-specific configurations.
Client: The client must associate one of the generator objects with the director. Usually, it's only done once, via the director's constructor parameters. The director then uses that builder object for all subsequent constructions.
However, there is an alternative approach where the client passes the builder object to the director's production method. In this case, you can use a different builder every time you produce something with the director.
For example: the Class Director does not directly create an assembly into a product Car and Manual. Instead, the Director class turns to the Builder Interface to create parts of a complex object, making the Director independent of which concrete classes are instantiated (what representation is generated).
The CarBuilder class implements the Builder interface by creating and assembling Car objects, and similarly, the CarManualBuilder class implements the Builder interface by creating and assembling Manual objects.
You can construct objects step-by-step, defer construction steps or run steps recursively.
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.
Allows you to change different instances of each product.
Calculating code encapsulation for construction.
Provides control over the steps of the construction process.
The overall complexity of the code increases since the pattern requires creating multiple new classes.
A separate ConcreteBuilder must be created for each product type.
Builder classes must be mutable
Make sure that you can clearly define the common construction steps for building all available product representations. Otherwise, you won’t be able to proceed with implementing the pattern.
Declare these steps in the base builder interface.
Create a concrete builder class for each of the product representations and implement their construction steps.
Don’t forget about implementing a method for fetching the result of the construction. The reason why this method can’t be declared inside the builder interface is that various builders may construct products that don’t have a common interface. Therefore, you don’t know what would be the return type for such a method. However, if you’re dealing with products from a single hierarchy, the fetching method can be safely added to the base interface.
Think about creating a director class. It may encapsulate various ways to construct a product using the same builder object.
The client code creates both the builder and the director objects. Before construction starts, the client must pass a builder object to the director. Usually, the client does this only once, via parameters of the director’s class constructor. The director uses the builder object in all further construction. There’s an alternative approach, where the builder is passed to a specific product construction method of the director.
The construction result can be obtained directly from the director only if all products follow the same interface. Otherwise, the client should fetch the result from the builder.
Composite: Provides a way to represent an entire partial hierarchy but a tree-like structure
Iterator: Provides a way to traverse the elements of an object structure .
Visitor: Provides a way to define new operations for elements of an object structure.
Interpreter: represents a sentence in a simple language as a composite object structure (abstract syntax tree).
