When to Use Which Creational Pattern — Decision Tree

You have learned five creational design patterns in Section 10 — Singleton, Factory Method, Abstract Factory, Builder, and Prototype. Each one solves a specific object creation problem. But when you sit in an LLD interview and the interviewer says "design a notification system" or "model an e-commerce product catalog," the real challenge is not knowing what these patterns are — it is knowing which one to reach for.

This tutorial gives you a systematic decision framework. Instead of guessing, you follow a structured flowchart that narrows down the right pattern based on your requirements. Think of it like a doctor's diagnostic flowchart — answer a few yes/no questions about your object creation needs, and the flowchart leads you to the correct pattern.

We will first walk through the decision logic in plain text, then provide a visual decision tree you can reference anytime, and finally compare all five patterns side-by-side.

Before the decision tree, here is a one-sentence summary of each pattern's core purpose:

• Singleton (S10, Tutorial 2): Ensures a class has exactly one instance and provides a global point of access to it. Use when a single shared resource must be coordinated across the system — like a configuration manager, connection pool, or logger.

• Factory Method (S10, Tutorial 3): Defines an interface for creating objects but lets subclasses decide which concrete class to instantiate. Use when the exact type of object to create depends on context that varies at runtime or across subclasses.

• Abstract Factory (S10, Tutorial 4): Creates families of related objects without specifying their concrete classes. Use when you need to produce groups of objects that must be used together — like UI widgets for different operating systems or database connectors for different vendors.

• Builder (S10, Tutorial 5): Separates the construction of a complex object from its representation, allowing the same construction process to create different representations. Use when an object has many optional parameters, requires multi-step construction, or has multiple valid configurations.

• Prototype (S10, Tutorial 6): Creates new objects by cloning an existing instance rather than constructing from scratch. Use when object creation is expensive, when you need copies of a configured object, or when you want to avoid a complex class hierarchy of factories.

When you encounter an object creation challenge, walk through these questions in order. Each question eliminates patterns that do not fit, narrowing your choice.

Question 1: Do you need exactly one instance shared across the entire application?

If the answer is yes — you need a global single point of access to a shared resource (a logger, a thread pool, a configuration store, a cache) — the answer is Singleton.

Be careful: Singleton is the most overused pattern. If you are using it just to avoid passing dependencies through constructors, you likely want Dependency Injection (S13) instead. Only use Singleton when having multiple instances would cause actual bugs (two connection pools competing, two loggers interleaving output, conflicting configuration states).

Question 2: Do you need to create families of related objects that must be used together?

If the answer is yes — you are building a system where objects come in matching sets (a Windows button + Windows checkbox + Windows scrollbar, or a MySQL connector + MySQL query builder + MySQL result parser) — the answer is Abstract Factory.

The key signal is "families." Abstract Factory ensures that you never accidentally mix a Windows button with a macOS checkbox — the factory produces a consistent set.

Question 3: Do you need to defer the decision of which class to instantiate to subclasses or runtime logic?

If the answer is yes — you know the interface of the object to create, but the concrete type varies based on context (a LogisticsApp that creates either Truck or Ship objects depending on whether it is road or sea logistics) — the answer is Factory Method.

The key signal is "which concrete class?" changes based on context, but the creator's code should not change. If you have a switch or if/else on type to decide what to construct, Factory Method replaces it with polymorphism.

Question 4: Is the object complex — with many optional parameters, multi-step assembly, or multiple valid configurations?

If the answer is yes — the object has 5+ constructor parameters (many optional), or construction involves multiple steps that must happen in sequence, or the same construction process should produce different representations (e.g., building an HTML report and a PDF report with the same steps) — the answer is Builder.

The key signals are telescoping constructors (constructors with 3, 4, 5, 6 parameters), optional configurations (most fields have sensible defaults), or step-by-step construction (you build a meal: choose main, choose side, choose drink, choose dessert).

Question 5: Is creating the object expensive, and do you need copies of an already-configured object?

If the answer is yes — the object requires costly setup (database queries, file reads, network calls), or you want to clone a prototype with pre-loaded configuration and tweak a few fields — the answer is Prototype.

The key signals are expensive initialization (deep object graphs, computed fields), preconfigured templates (a "default user settings" object that gets cloned and customized for each new user), or avoiding parallel factory class hierarchies (if Factory Method would require mirroring every product class with a factory class, Prototype avoids that by cloning instead).

Still not sure? Default to a simple constructor.

If none of these questions produced a clear "yes," you probably do not need a creational pattern at all. A regular constructor or a simple static factory method (User.create(name, email)) is fine. Patterns add complexity — only use them when the complexity they add is less than the complexity they remove.

Factory Method vs Abstract Factory

This is the most common confusion. Here is the clearest distinction:

• Factory Method creates one product. A LogisticsApp subclass decides whether to create a Truck or a Ship. There is one method, one product type, one decision.

• Abstract Factory creates a family of products. A UIFactory creates a Button AND a Checkbox AND a Scrollbar — all matching the same theme. There are multiple methods, multiple product types, all consistent.

Rule of thumb: If you are switching only the type of one object → Factory Method. If you are switching the entire family of related objects → Abstract Factory.

Builder vs Factory Method

• Factory Method focuses on which class to instantiate. The construction itself is simple (one constructor call).

• Builder focuses on how to construct a complex object. The class is known — it is the construction process that varies (which optional fields to set, which steps to include).

Rule of thumb: If the challenge is "what to create" → Factory. If the challenge is "how to construct it" → Builder.

Prototype vs Factory Method

• Factory Method creates new objects from scratch via constructors.

• Prototype creates new objects by copying an existing, already-configured instance.

Rule of thumb: If object setup is cheap → Factory. If object setup is expensive (deep graphs, computed state, loaded resources) and you have a ready-made template → Prototype.

In an LLD interview, naming the right pattern is important — but explaining why is what earns points. Use this template when proposing a creational pattern:

"I am choosing [Pattern] here because [specific problem it solves in this design]. The alternative would be [what you'd do without it], but that would [specific downside]."

For example:

"I am choosing Builder for MeetingRequest because it has 8 fields — title, organizer, attendees, room, start time, end time, recurrence, and priority — most of which are optional. The alternative would be a constructor with 8 parameters, but that would make call sites unreadable and error-prone with positional arguments."

This demonstrates understanding, not just memorization. Refer to the Interview Framework in S16 for the complete approach.

Here is where each creational pattern appears in the Design Problems course:

• Singleton: Logging Framework (single logger instance), Vending Machine (single machine controller)
• Factory Method: Parking Lot (vehicle creation by type), Car Rental (vehicle types), Shopping System (product creation), Airline Booking (seat classes), Hotel Booking (room types)
• Abstract Factory: Useful when design problems require themed UI or database vendor abstraction — less common in standard LLD interview problems
• Builder: Meeting Scheduler (complex meeting request construction with many optional fields)
• Prototype: Useful when problems involve template-based object creation — e.g., default configurations that get cloned and customized

When you encounter these design problems, you will recognize the pattern instantly because you know the decision criteria.

• Use the decision tree — do not guess which creational pattern to use. Walk through the five questions in order
• Singleton = exactly one instance. Be cautious of overuse — prefer Dependency Injection (S13) when you just want to share a dependency
• Factory Method = "which class?" decided by subclasses. Replaces switch/if-else on type with polymorphism
• Abstract Factory = families of related objects that must match. The signal is multiple products that come in themed sets
• Builder = complex object with many optional parameters or multi-step construction. Eliminates telescoping constructors
• Prototype = clone an existing configured object instead of constructing from scratch. Best when setup is expensive
• If no question in the decision tree produces a clear "yes," a plain constructor or static factory method is the right choice — not every creation problem needs a pattern