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

Design: Creational Design Patterns Usage Guide

Focus on the five main creational patterns: Singleton, Factory Method, Abstract Factory, Builder, Prototype. Exclude structural and behavioral patterns.

Functional Requirements

FR1: Explain when to use common creational design patterns

FR2: Provide clear criteria for choosing each pattern

FR3: Include examples of scenarios for each pattern

FR4: Support understanding for beginners and non-technical learners

Non-Functional Requirements

NFR1: Use simple language without jargon

NFR2: Keep explanations concise and relatable

NFR3: Focus on practical decision-making, not code details

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Singleton pattern for single instance control

Factory Method for flexible object creation

Abstract Factory for creating related object families

Builder for complex object construction

Prototype for cloning objects

Design Patterns

Singleton

Factory Method

Abstract Factory

Builder

Prototype

Reference Architecture

  +-------------------+       +-------------------+       +-------------------+
  |   Singleton       |       |   Factory Method   |       |  Abstract Factory  |
  |  (Single Instance)|       | (Create Objects)   |       | (Families of Obj)  |
  +---------+---------+       +---------+---------+       +---------+---------+
            |                           |                           |
            |                           |                           |
            v                           v                           v
  +-------------------+       +-------------------+       +-------------------+
  |    Builder        |       |    Prototype      |       |   Client Code      |
  | (Step-by-step     |       | (Clone Objects)   |       | (Uses Patterns)    |
  |  Construction)    |       +-------------------+       +-------------------+

Components

Singleton

Any OOP language

Ensure only one instance of a class exists and provide a global access point.

Factory Method

Any OOP language

Define an interface for creating an object but let subclasses decide which class to instantiate.

Abstract Factory

Any OOP language

Create families of related or dependent objects without specifying their concrete classes.

Builder

Any OOP language

Separate the construction of a complex object from its representation so the same construction process can create different representations.

Prototype

Any OOP language

Create new objects by copying an existing object, useful when object creation is costly.

Request Flow

1. Client needs an object and identifies the creation problem.

2. If only one instance is needed, use Singleton to get the instance.

3. If object creation varies by subclass, use Factory Method to delegate creation.

4. If a group of related objects is needed, use Abstract Factory to create them together.

5. If object construction is complex, use Builder to build it step-by-step.

6. If cloning existing objects is efficient, use Prototype to copy them.

7. Client uses the created object without worrying about creation details.

Database Schema

Not applicable for this conceptual design.

Scaling Discussion

Bottlenecks

Singleton can become a bottleneck if used in multithreaded environments without proper synchronization.

Factory Method and Abstract Factory can lead to many subclasses, increasing complexity.

Builder pattern may add overhead if object construction is simple.

Prototype requires careful cloning logic to avoid shared mutable state.

Solutions

Use thread-safe Singleton implementations or dependency injection to avoid bottlenecks.

Keep factory hierarchies manageable and use composition to reduce subclass explosion.

Use Builder only when object construction complexity justifies it.

Implement deep cloning carefully and document cloning behavior clearly.

Interview Tips

Time: Spend 10 minutes explaining each pattern briefly, 10 minutes discussing when to use them, and 5 minutes answering questions or giving examples.

Explain the problem each pattern solves in simple terms.

Describe real-life analogies (e.g., Singleton as a single remote control).

Discuss trade-offs and when not to use a pattern.

Show understanding of how patterns help manage object creation complexity.

Mention thread safety and complexity concerns where relevant.

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