Patterns: Builder
Published: 01/03/25 by stsykalovskyi
Pattern Name
Builder
Description:
The Builder pattern separates the construction of a complex object from its representation. This allows the same construction process to create different representations of an object. It is typically used to create an object with many optional parts, where the creation logic can be complex and require flexibility.
Category
Creational
Problem Statement
Context:
When an object requires numerous configurations or has many parts, constructing it in a single step can be cumbersome and error-prone. Multiple constructors or large, complex initialization code could clutter the codebase, leading to low maintainability.
Example:
Consider building a computer with various components, such as a CPU, GPU, RAM, storage, and more. These components vary in type, and some are optional. A single constructor with a large number of parameters would be hard to manage and extend.
Solution
Concept:
The Builder pattern addresses this issue by abstracting the construction process. It allows creating an object step by step, using a builder that takes care of the object's construction. The client can choose which components to include and how to configure the object, keeping the construction process flexible and manageable.
Diagram:
+----------------+ +---------------------+ +----------------------+
| Director | | Builder | | Product |
+----------------+ +---------------------+ +----------------------+
| construct() |<>------| build_part_a() | | component_a |
+----------------+ | build_part_b() | | component_b |
| build_part_c() | | component_c |
+---------------------+ +----------------------+
^ ^
| |
+-----------------------------+ +--------------------------+
| ConcreteBuilder | | ConcreteProduct |
+-----------------------------+ +--------------------------+
| build_part_a() | | product |
| build_part_b() | +--------------------------+
| build_part_c() |
+-----------------------------+
Implementation:
# Product: The complex object that will be created
class Computer:
def __init__(self):
self.cpu = None
self.ram = None
self.storage = None
self.gpu = None
def __str__(self):
return f"Computer with CPU: {self.cpu}, RAM: {self.ram}, Storage: {self.storage}, GPU: {self.gpu}"
# Builder Interface: Specifies the construction process
class ComputerBuilder:
def build_cpu(self):
pass
def build_ram(self):
pass
def build_storage(self):
pass
def build_gpu(self):
pass
def get_result(self):
pass
# ConcreteBuilder: Implements the Builder interface
class GamingComputerBuilder(ComputerBuilder):
def __init__(self):
self.computer = Computer()
def build_cpu(self):
self.computer.cpu = "Intel Core i9"
def build_ram(self):
self.computer.ram = "32GB DDR4"
def build_storage(self):
self.computer.storage = "1TB SSD"
def build_gpu(self):
self.computer.gpu = "NVIDIA RTX 3090"
def get_result(self):
return self.computer
class OfficeComputerBuilder(ComputerBuilder):
def __init__(self):
self.computer = Computer()
def build_cpu(self):
self.computer.cpu = "Intel Core i5"
def build_ram(self):
self.computer.ram = "8GB DDR4"
def build_storage(self):
self.computer.storage = "500GB SSD"
def build_gpu(self):
self.computer.gpu = "Integrated GPU"
def get_result(self):
return self.computer
# Director: Directs the construction process
class Director:
def __init__(self, builder):
self.builder = builder
def construct(self):
self.builder.build_cpu()
self.builder.build_ram()
self.builder.build_storage()
self.builder.build_gpu()
# Client code
gaming_builder = GamingComputerBuilder()
director = Director(gaming_builder)
director.construct()
gaming_computer = gaming_builder.get_result()
print(gaming_computer)
office_builder = OfficeComputerBuilder()
director = Director(office_builder)
director.construct()
office_computer = office_builder.get_result()
print(office_computer)
Participants
- Product: The complex object that is being constructed (e.g., Computer).
- Builder: The abstract interface for constructing the parts of the product.
- ConcreteBuilder: Implements the Builder interface, constructing the product step by step.
- Director: Oversees the construction process, ensuring that the product is constructed in a particular sequence.
- Client: Uses the Director to build the product using a specific builder.
Advantages
- Separation of Concerns: Keeps the construction process separate from the object's representation, leading to cleaner and more maintainable code.
- Flexibility: Allows constructing different representations of the product (e.g., a gaming computer vs. an office computer).
- Reusability: Builders can be reused for different parts or configurations of objects.
- Code Readability: The construction code is easy to read and understand because the product is built step by step.
Drawbacks
- Complexity: The pattern introduces additional classes (builder, director, and product), which can increase complexity when the object is simple or has few configurations.
- Tight Coupling: The Director class is tightly coupled to the Builder interface, which can make it difficult to use multiple builders at the same time.
Use Cases
- Creating objects that need to be initialized with many parts, like a computer, car, or house.
- Complex UI elements, where you need to define parts like buttons, text fields, and images in a flexible way.
- Generating reports or documents where multiple sections need to be constructed step by step (e.g., HTML or PDF generation).
Related Patterns
- Abstract Factory: The Builder pattern is useful for complex objects, while Abstract Factory focuses on creating families of related objects.
- Factory Method: The Builder pattern allows for more flexible and step-by-step construction of an object compared to the Factory Method's single-step object creation.
Category: Programming
Tags: patterns