When to use which creational pattern in LLD - Deep Dive

Overview - When to use which creational pattern

What is it?

Creational patterns are design solutions that help create objects in a flexible and controlled way. They guide how to instantiate objects depending on the situation, making code easier to manage and extend. This topic explains when to choose each creational pattern based on the problem you face. It helps beginners understand the right tool for creating objects in software design.

Why it matters

Without knowing when to use each creational pattern, developers might create code that is hard to change, test, or reuse. This can lead to bugs, slow development, and poor software quality. Using the right pattern saves time and effort by providing clear ways to build objects that fit the needs of the system. It also helps teams communicate better by using common design ideas.

Where it fits

Before this, learners should understand basic object-oriented programming concepts like classes and objects. They should also know what design patterns are in general. After this, learners can explore structural and behavioral design patterns, which focus on how objects relate and interact.

Mental Model

Core Idea

Choose the creational pattern that best fits how and when you need to create objects to keep your code flexible and easy to maintain.

Think of it like...

It's like choosing the right kitchen tool: sometimes you need a simple spoon, other times a blender or a mixer, depending on the recipe and the result you want.

╔════════════════════════════════════════════╗
║          Creational Patterns Guide         ║
╠══════════════════╦═══════════════════════╣
║ Pattern          ║ When to Use            ║
╠══════════════════╬═══════════════════════╣
║ Singleton        ║ One instance needed    ║
║ Factory Method   ║ Subclasses decide type ║
║ Abstract Factory ║ Families of objects    ║
║ Builder          ║ Step-by-step creation  ║
║ Prototype        ║ Clone existing objects ║
╚══════════════════╩═══════════════════════╝

Build-Up - 8 Steps

1

Foundation

Understanding Object Creation Basics

Concept: Learn what object creation means and why it matters in programming.

Objects are the building blocks of software. Creating them means making instances of classes. Simple creation works fine for small programs, but as programs grow, creating objects directly can cause problems like tight coupling and hard-to-change code.

Result

You understand that object creation is more than just calling a constructor; it affects how flexible and maintainable your code is.

Understanding that object creation impacts code structure is the first step to appreciating creational patterns.

2

Foundation

Introduction to Creational Patterns

Concept: Creational patterns provide standard ways to create objects that solve common problems.

There are five main creational patterns: Singleton, Factory Method, Abstract Factory, Builder, and Prototype. Each solves a different problem about how and when to create objects. They help keep code flexible and reusable.

Result

You know the names and basic purpose of each creational pattern.

Knowing the variety of creational patterns prepares you to choose the right one for your needs.

3

Intermediate

When to Use Singleton Pattern

🤔Before reading on: do you think Singleton is good for any object that is used many times? Commit to your answer.

Concept: Singleton ensures only one instance of a class exists and provides a global access point to it.

Use Singleton when you need exactly one object to coordinate actions across the system, like a configuration manager or a logging service. Avoid it if you need multiple instances or if global state causes problems.

Result

You can identify situations where a single shared instance is necessary and apply Singleton correctly.

Understanding Singleton's role helps prevent overusing it, which can cause hidden dependencies and testing difficulties.

4

Intermediate

Choosing Factory Method Pattern

🤔Before reading on: do you think Factory Method lets subclasses decide which object to create? Commit to yes or no.

Concept: Factory Method lets subclasses decide which class to instantiate, promoting flexibility and reuse.

Use Factory Method when a class can't anticipate the type of objects it needs to create, or when subclasses should specify the objects. This pattern helps avoid tight coupling between creator and product classes.

Result

You can design systems where object creation is delegated to subclasses, making code easier to extend.

Knowing Factory Method's delegation principle helps you design flexible and scalable class hierarchies.

5

Intermediate

Applying Abstract Factory Pattern

🤔Before reading on: do you think Abstract Factory creates single objects or groups of related objects? Commit to your answer.

Concept: Abstract Factory creates families of related objects without specifying their concrete classes.

Use Abstract Factory when your system needs to work with multiple families of related objects, and you want to ensure they are used together. For example, UI themes with matching buttons, menus, and windows.

Result

You can build systems that easily switch between different object families without changing client code.

Understanding Abstract Factory's grouping of related objects helps maintain consistency and flexibility in complex systems.

6

Advanced

Builder Pattern for Complex Object Creation

🤔Before reading on: do you think Builder is useful when objects need many steps to create? Commit to yes or no.

Concept: Builder separates the construction of a complex object from its representation, allowing step-by-step creation.

Use Builder when creating an object requires multiple steps or configurations, and you want to avoid a constructor with many parameters. It also helps create different representations of the object using the same construction process.

Result

You can create complex objects in a controlled way, improving code readability and flexibility.

Knowing Builder helps manage complexity in object creation and supports different product variations.

7

Advanced

Prototype Pattern for Cloning Objects

🤔Before reading on: do you think Prototype creates new objects by copying existing ones? Commit to yes or no.

Concept: Prototype creates new objects by cloning existing instances, avoiding costly creation processes.

Use Prototype when creating a new object is expensive or complex, and you can copy an existing object instead. This pattern is useful when objects have many configurations or when runtime object creation is costly.

Result

You can efficiently create new objects by cloning, saving time and resources.

Understanding Prototype helps optimize object creation in performance-critical systems.

8

Expert

Combining Patterns for Real-World Solutions

🤔Before reading on: do you think creational patterns can be combined in one system? Commit to yes or no.

Concept: In complex systems, multiple creational patterns often work together to solve different parts of the object creation problem.

For example, a system might use Singleton for a global configuration, Factory Method for creating product variants, and Builder for assembling complex objects. Knowing when and how to combine patterns leads to robust and maintainable designs.

Result

You can design flexible systems that use the strengths of multiple creational patterns together.

Recognizing pattern combinations unlocks advanced design skills and prepares you for real-world software architecture.

Under the Hood

Creational patterns control object creation by abstracting the instantiation process. Singleton uses static variables and controlled access to ensure one instance. Factory Method and Abstract Factory use inheritance and interfaces to defer object creation to subclasses or families. Builder separates construction steps using a director and builder interface. Prototype uses cloning methods to copy objects. These mechanisms reduce direct dependencies and improve flexibility.

Why designed this way?

These patterns emerged to solve common problems in object-oriented design where direct object creation caused tight coupling and inflexible code. They balance the need for reuse, extension, and separation of concerns. Alternatives like direct instantiation or large constructors were rejected because they made code hard to maintain and test.

╔════════════════════════════════════════════════════════╗
║                    Object Creation Flow                 ║
╠══════════════╦════════════════════════════════════════╣
║ Client Code  ║ Requests object creation                ║
╠══════════════╬════════════════════════════════════════╣
║ Creational   ║ Decides how to create object:           ║
║ Pattern      ║ - Singleton: returns single instance    ║
║              ║ - Factory Method: calls subclass method  ║
║              ║ - Abstract Factory: creates object family║
║              ║ - Builder: constructs step-by-step       ║
║              ║ - Prototype: clones existing object      ║
╠══════════════╬════════════════════════════════════════╣
║ Product      ║ New object created and returned          ║
╚══════════════╩════════════════════════════════════════╝

Myth Busters - 4 Common Misconceptions

Quick: Is Singleton pattern always the best way to share data globally? Commit to yes or no.

Common Belief: Singleton is the best way to share data globally because it guarantees one instance.

Reality: Singleton can cause hidden dependencies and make testing hard; sometimes dependency injection or other patterns are better.

Why it matters: Overusing Singleton leads to tightly coupled code and difficulties in unit testing and parallel development.

Quick: Does Factory Method mean the factory class creates all objects directly? Commit to yes or no.

Common Belief: Factory Method means the factory class creates all objects itself.

Reality: Factory Method defers object creation to subclasses, not the factory class itself.

Why it matters: Misunderstanding this leads to rigid code that is hard to extend or modify.

Quick: Can Builder pattern be replaced by a constructor with many parameters? Commit to yes or no.

Common Belief: Builder is just a fancy constructor with many parameters.

Reality: Builder separates construction steps and supports different representations, which constructors cannot do cleanly.

Why it matters: Using large constructors instead of Builder leads to confusing and error-prone code.

Quick: Does Prototype always create a deep copy of objects? Commit to yes or no.

Common Belief: Prototype always creates a deep copy of the object.

Reality: Prototype can create shallow or deep copies depending on implementation; deep copying is more complex and costly.

Why it matters: Assuming deep copy can cause bugs if shared references are not handled properly.

Expert Zone

1

Singleton pattern can be thread-safe or not; improper implementation causes race conditions in concurrent environments.

2

Abstract Factory often works with Factory Method internally, combining patterns for flexible object families.

3

Builder pattern can separate the construction algorithm from the product representation, enabling reuse of construction code.

When NOT to use

Avoid Singleton when global state causes tight coupling or testing issues; use dependency injection instead. Skip Factory Method if object types are fixed and simple. Don't use Builder for simple objects with few parameters. Prototype is not suitable if cloning is expensive or complex; consider Factory instead.

Production Patterns

In real systems, Singleton is used for logging or configuration managers. Factory Method is common in UI frameworks to create widgets. Abstract Factory supports theme switching in applications. Builder is used in constructing complex documents or queries. Prototype is used in game development for cloning characters or objects.

Connections

Dependency Injection

Alternative and complement to Singleton for managing object lifetimes and dependencies

Understanding when to use Singleton versus Dependency Injection helps design more testable and flexible systems.

Software Architecture Principles

Creational patterns support principles like SOLID, especially Single Responsibility and Open/Closed principles

Knowing creational patterns deepens understanding of how to keep code modular and extendable.

Manufacturing Processes

Both involve choosing the right method to produce items efficiently and consistently

Seeing object creation like manufacturing helps grasp why different patterns suit different production needs.

Common Pitfalls

#1 Using Singleton for every shared object without considering testability.

Wrong approach:

class Logger {
private static Logger instance;
private Logger() {}
public static Logger getInstance() {
if (instance == null) {
instance = new Logger();
}
return instance;
}
// Logger methods
}
// Used everywhere directly

Correct approach:

class Logger {
// No static instance
// Inject Logger where needed
}
// Use dependency injection to provide Logger instances

Root cause:

Belief that Singleton is the easiest way to share objects leads to ignoring better design practices.

#2 Factory Method implemented with fixed object creation in base class.

Wrong approach:

class Creator {
Product factoryMethod() {
return new ConcreteProduct();
}
}
// No subclass override

Correct approach:

abstract class Creator {
abstract Product factoryMethod();
}
class ConcreteCreator extends Creator {
Product factoryMethod() {
return new ConcreteProduct();
}
}

Root cause:

Not understanding that Factory Method requires subclasses to override creation method.

#3 Builder pattern replaced by constructor with many parameters.

Wrong approach:

class House {
House(int windows, int doors, boolean hasGarage, boolean hasPool, String roofType) {
// many parameters
}
}

Correct approach:

class HouseBuilder {
// step-by-step methods to set parts
House build() {
return new House(...);
}
}

Root cause:

Ignoring complexity of object creation leads to unwieldy constructors.

Key Takeaways

Creational patterns guide how to create objects flexibly and maintainably in software design.

Choosing the right pattern depends on the problem: single instance, family of objects, complex construction, or cloning.

Misusing patterns like Singleton can cause hidden dependencies and testing challenges.

Combining creational patterns in one system is common and leads to robust designs.

Understanding these patterns deeply improves your ability to build scalable and adaptable software.

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