When to use which creational pattern in LLD - System Design Guide

Problem Statement

Creating objects directly in code can lead to rigid designs that are hard to change or extend. Without a clear approach, adding new types or changing creation logic often requires modifying many parts of the code, increasing bugs and slowing development.

Solution

Creational patterns provide structured ways to create objects, separating the creation logic from usage. Each pattern fits different needs: some create one instance, others create families of related objects, and some allow flexible object creation without specifying exact classes upfront.

Architecture

Client Code

→Creator

↓

ConcreteProdA

This diagram shows client code requesting objects from a creator interface, which then instantiates concrete product classes. It illustrates the Factory Method pattern where creation is delegated.

Trade-offs

✓ Pros

→

Improves code flexibility by decoupling object creation from usage.

→

Makes it easier to introduce new types without changing existing code.

→

Supports single instance control (Singleton) or complex object construction (Builder).

→

Enhances testability by allowing mock or stub objects creation.

✗ Cons

→

Adds extra layers of abstraction, which can increase code complexity.

→

May introduce more classes and interfaces, making the codebase larger.

→

Choosing the wrong pattern can lead to over-engineering or insufficient flexibility.

Use creational patterns when object creation is complex, needs to be controlled, or when the system must support multiple types or configurations of objects. For example, when you want to avoid tight coupling between client code and concrete classes or when you need to manage object lifecycle carefully.

Avoid using creational patterns for simple object creation where direct instantiation is clear and sufficient, especially when the system has low complexity or when performance is critical and the overhead of abstraction is not justified.

Real World Examples

Netflix

Uses the Builder pattern to construct complex streaming session objects with many optional parameters, improving code clarity and flexibility.

Uber

Applies the Factory Method pattern to create different types of ride requests (e.g., UberX, UberPool) without changing client code.

Amazon

Employs the Singleton pattern for managing shared resources like configuration settings and database connection pools.

Code Example

The before code creates a Car object directly, which ties client code to a specific class. The after code uses a factory method to create car objects, allowing easy extension to new car types without changing client code.

LLD

### Before: Direct instantiation (tight coupling)
class Car:
    def __init__(self, model):
        self.model = model

car = Car('Sedan')

### After: Using Factory Method pattern
from abc import ABC, abstractmethod

class Car(ABC):
    @abstractmethod
    def drive(self):
        pass

class Sedan(Car):
    def drive(self):
        print('Driving a sedan')

class Suv(Car):
    def drive(self):
        print('Driving an SUV')

class CarFactory:
    @staticmethod
    def create_car(car_type):
        if car_type == 'sedan':
            return Sedan()
        elif car_type == 'suv':
            return Suv()
        else:
            raise ValueError('Unknown car type')

car = CarFactory.create_car('sedan')
car.drive()

Alternatives

Prototype

Creates new objects by cloning existing instances rather than building from scratch.

Use when: When object creation is expensive and you want to copy existing objects with some modifications.

Abstract Factory

Provides an interface to create families of related objects without specifying their concrete classes.

Use when: When you need to create multiple related objects that must be used together and want to ensure compatibility.

Builder

Separates the construction of a complex object from its representation, allowing step-by-step creation.

Use when: When an object requires many steps or configurations to be created and you want to isolate that complexity.

Summary

Creational patterns help manage complex object creation and improve code flexibility.

Each pattern fits different scenarios, such as single instance control, family creation, or stepwise construction.

Choosing the right pattern depends on system complexity, object relationships, and future extensibility needs.

Practice

1. Which creational pattern is best when you need only one instance of a class throughout the application?

easy

A. Singleton pattern

B. Factory pattern

C. Builder pattern

D. Prototype pattern

Solution

1. Step 1: Understand the requirement for a single instance

   The question asks for a pattern that ensures only one instance of a class exists.

2. Step 2: Match the pattern to the requirement

   Singleton pattern restricts instantiation to one object and provides a global access point.

3. Final Answer:

   Singleton pattern -> Option A

4. Quick Check:

   Single instance = Singleton [OK]

Hint: Single instance? Think Singleton pattern [OK]

Common Mistakes:

• Confusing Factory with Singleton
• Using Builder for single instance
• Thinking Prototype creates single instance

2. Which creational pattern allows creating different types of objects without specifying their concrete classes directly?

easy

A. Singleton pattern

B. Factory pattern

C. Builder pattern

D. Adapter pattern

Solution

1. Step 1: Identify the pattern for flexible object creation

   The question wants a pattern that creates objects without exposing the creation logic.

2. Step 2: Match the pattern to the description

   Factory pattern provides an interface to create objects but lets subclasses decide which class to instantiate.

3. Final Answer:

   Factory pattern -> Option B

4. Quick Check:

   Flexible object creation = Factory [OK]

Hint: Flexible creation? Use Factory pattern [OK]

Common Mistakes:

• Choosing Singleton for flexible creation
• Confusing Builder with Factory
• Selecting Adapter which is not creational

3. Consider this code snippet using the Builder pattern:

class CarBuilder {
  constructor() {
    this.car = new Car();
  }
  setColor(color) {
    this.car.color = color;
    return this;
  }
  setWheels(wheels) {
    this.car.wheels = wheels;
    return this;
  }
  build() {
    return this.car;
  }
}

const car = new CarBuilder().setColor('red').setWheels(4).build();
console.log(car.color, car.wheels);

What will be the output?

medium

A. red 4

B. undefined undefined

C. red undefined

D. Error: Car is not defined

Solution

1. Step 1: Check if Car class is defined

   The code uses new Car() but Car class is not defined anywhere, causing a runtime error.

2. Step 2: Understand the consequence of missing class

   Since Car is undefined, the code throws a ReferenceError before any properties are set.

3. Final Answer:

   Error: Car is not defined -> Option D

4. Quick Check:

   Missing class definition = ReferenceError [OK]

Hint: Check if all classes are defined before use [OK]

Common Mistakes:

• Assuming output is 'red 4' without Car class
• Ignoring missing class error
• Confusing Builder pattern with Factory output

4. You have a Singleton class implemented as below:

class Logger {
  constructor() {
    if (Logger.instance) {
      return Logger.instance;
    }
    this.logs = [];
    Logger.instance = this;
  }
  log(message) {
    this.logs.push(message);
  }
}

What is the main issue with this implementation?

medium

A. It creates a new instance every time

B. It does not store logs properly

C. It does not prevent multiple instances

D. It lacks a method to retrieve logs

Solution

1. Step 1: Analyze Singleton enforcement

   The constructor returns existing instance if present, but the implementation does not fully prevent multiple instances.

2. Step 2: Identify the issue in JavaScript context

   In JavaScript, this pattern works but can be bypassed by other means; better to use static method to get instance.

3. Final Answer:

   It does not prevent multiple instances -> Option C

4. Quick Check:

   Singleton enforcement flaw = It does not prevent multiple instances [OK]

Hint: Singleton needs controlled instance creation [OK]

Common Mistakes:

• Thinking logs are not stored
• Assuming new instance is always created
• Ignoring missing retrieval method

5. You are designing a system to create complex meal orders with many optional parts (drink, main dish, dessert). Which creational pattern is most suitable and why?

hard

A. Builder pattern, because it simplifies creating complex objects step-by-step

B. Singleton pattern, because only one meal order should exist

C. Factory pattern, because it creates different meal types without specifying details

D. Prototype pattern, because it clones existing meal orders

Solution

1. Step 1: Understand the complexity of the object

   Meal orders have many optional parts and require step-by-step construction.

2. Step 2: Match pattern to complex object creation

   Builder pattern is designed to build complex objects step-by-step, allowing optional parts to be added flexibly.

3. Final Answer:

   Builder pattern, because it simplifies creating complex objects step-by-step -> Option A

4. Quick Check:

   Complex object with options = Builder [OK]

Hint: Complex object? Use Builder pattern [OK]

Common Mistakes:

• Choosing Singleton for multiple orders
• Confusing Factory with Builder for complex objects
• Using Prototype without cloning need