Jul 1

Understanding Factory and Builder Creational Design Patterns in Java

Write your awesome label here.
The four pillars of object-oriented programming are abstraction, polymorphism, inheritance, and encapsulation (A-P-I-E).

1. Abstraction: This is the concept of hiding the complex implementation details and showing only the essential features of the object. It simplifies the design and enhances the understanding of the software system.

2. Polymorphism: This allows objects to be treated as instances of their parent class rather than their actual class. Polymorphism enables a single function to work in different ways depending on the context, improving flexibility and maintainability.

3. Inheritance: This allows a new class to inherit the properties and behavior of an existing class. It promotes code reusability and establishes a natural hierarchical relationship between classes.

4. Encapsulation: This is the practice of wrapping data (variables) and methods (functions) that operate on the data into a single unit, known as a class. Encapsulation helps in protecting the data from outside interference and misuse.

Above OOPS concepts provide the foundation upon which design patterns are built but remember that design patterns are guidelines and not strict rules. They can be modified to fit the specific needs of a project/use case.

Creational Design Patterns

Creational design patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. These patterns aim to make the system independent of how its objects are created, composed, and represented.

In this blog post, we will discuss about Factory and Builder patterns

Factory Pattern

The Factory Pattern is a creational design pattern that defines an interface or method for creating an object but allows subclasses or methods to decide which class to instantiate. It helps in creating objects without exposing the instantiation logic to the client and refers to the newly created object through a common interface.
Centralized Creation: Just as a physical factory centralizes the production of items, a software factory centralizes the creation of objects. This centralization means that the logic for creating an object is not spread throughout the code but is instead located in a single place, making it easier to manage and update.

Abstraction: In a physical factory, the details of how products are made are hidden from the consumers. Similarly, in a software factory, the details of how objects are instantiated are hidden from the client code. The client only needs to know how to request an object, not how to create it.

Separation of Concerns: By handling object creation in a factory, the pattern adheres to the principle of separation of concerns. The client code is concerned with what it wants to do with the object, while the factory is concerned with how to create the object.

How to achieve Factory Pattern in the code

1. Creator Interface or Abstract Class
The creator defines an interface or an abstract class that declares the factory method.
This method should return an object of a product type.

2. Concrete Creators
Concrete creators implement the factory method to produce concrete products. These concrete creators provide the actual implementation of the factory method declared in the creator.

3. Product Interface or Abstract Class
The product interface or abstract class defines the type of object the factory method creates. It declares the operations that all concrete products must implement

4. Concrete Products
Concrete products implement the product interface. Each concrete product corresponds to a specific concrete creator.
What Was Achieved Using the Factory Pattern in above code

  • Encapsulation of Object Creation: The LoggerFactory encapsulates the logic of creating different types of loggers. The client code does not need to know the specifics of object creation and only interacts with the factory.

  • Separation of Concerns: The client code is separated from the concrete implementations of the loggers. It only relies on the Logger interface, promoting loose coupling.

  • Scalability: New types of loggers can be easily added without modifying the existing client code. You only need to add a new class that implements the Logger interface and update the LoggerFactory to handle the new type.

  • Single Responsibility Principle: The responsibility of creating loggers is assigned to the LoggerFactory, while the loggers themselves are responsible for logging messages.

  • Open/Closed Principle: The system is open for extension (new loggers can be added) but closed for modification (existing code does not need to change to add new loggers).

Empty space, drag to resize

Builder Pattern

The Builder Pattern is a creational design pattern that provides a flexible solution to constructing complex objects. It decouples the construction of an object from its representation, making it possible to use the same construction process to create different representations.
Key Concepts of the Builder Pattern

1. Separation of Construction and Representation

The Builder Pattern separates the process of constructing an object from the final representation of that object. This means that the logic for building an object is contained within the builder, and the client does not need to know the details of the construction process.

2. Step-by-Step Construction

Complex objects are built step by step, with each step handled by the builder. This approach allows for more control over the construction process, ensuring that the final product is assembled correctly.

3. Reusability

The Builder Pattern allows for the reuse of the construction process to create different types of objects. By changing the parameters and sequence of construction steps, the same builder can create variations of the final product

How to achieve Builder Pattern in the code

1. Product
The product is the complex object that is being built. It contains various parts that need to be constructed. The product class typically includes fields for these parts, along with methods to set and get these fields.

  • Design: The product class defines all the necessary attributes of the final object. It may also include methods to display or operate on these attributes.
  • Implementation: The product class provides setters (or public fields) that the builder will use to set the attributes. It can also provide a method to present the constructed object.

2. Builder Interface or Abstract Builder
The builder interface or abstract builder declares the construction steps that must be implemented by concrete builders. This interface ensures that all builders follow the same construction process.

  • Design: The builder interface defines methods for setting different parts of the product. These methods typically return the builder itself to allow for method chaining.
  • Implementation: The abstract builder can provide default implementations for some methods if needed. The key point is to define the methods necessary for constructing the product.

3. Concrete Builders
Concrete builders implement the builder interface and provide specific implementations for constructing and assembling parts of the product. Each concrete builder creates and assembles the parts of the product in its own way.

  • Design: Each concrete builder is responsible for constructing a specific variant of the product. It overrides the methods defined in the builder interface to build and assemble parts accordingly.
  • Implementation: Concrete builders maintain an instance of the product being built. They implement the methods defined in the builder interface to set various parts of this product.

4. Director
The director is an optional component that orchestrates the construction process. It knows which steps to execute to produce the final product. The director uses a builder instance to construct the product.

  • Design: The director defines the sequence in which to call the builder methods to create and assemble the product.
  • Implementation: The director accepts a builder instance (or a list of builders) and invokes the construction methods in a specific order. It may also provide methods to construct different configurations of the product.

5. Client
The client is the code that uses the builder pattern to create complex objects. The client creates a builder instance and passes it to the director (if used) or directly calls the builder methods to construct the product.

  • Design: The client is aware of the builder interface and concrete builders but not the specifics of the construction process. It relies on the builder (and optionally the director) to produce the product.
  • Implementation: The client initializes the builder and uses it to construct the product. It can directly call the builder methods or use the director to manage the construction process. Finally, it retrieves the constructed product from the builder.
What Was Achieved Using the Builder Pattern in above code

  • Simplified Object Creation: Easy and clear construction of objects with required and optional parameters.

  • Enhanced Readability and Maintainability: Clear and readable code for object creation, making it easy to understand and maintain.

  • Immutability: Ensured that Computer objects are immutable, enhancing their robustness and thread-safety.

  • Separation of Concerns: Separated the construction logic from the Computer class, making the codebase cleaner and more manageable.

  • Flexibility in Object Construction: Allowed for flexible and customizable object creation without worrying about the order of setting attributes.

  • Adherence to the Single Responsibility Principle: Ensured that each class has a single responsibility, resulting in a more modular and maintainable codebase.
Created with