Factory Method Pattern

---

Dark Mode

Show Highlights

Audio Clips

Context

In software construction, we often find ourselves in situations where a “Creator” class needs to manage a lifecycle of actions—such as preparing, processing, and delivering an item—but the specific type of item it handles varies based on the environment.

For example, imagine a PizzaStore that needs to orderPizza(). The store follows a standard process: it must prepare(), bake(), cut(), and box() the pizza. However, the specific type of pizza (New York style vs. Chicago style) depends on the store’s physical location. The “Context” here is a system where the high-level process is stable, but the specific objects being acted upon are volatile and vary based on concrete subclasses.

Problem

Without a creational pattern, developers often resort to “Big Upfront Logic” using complex conditional statements. You might see code like this:

public Pizza orderPizza(String type) {
    Pizza pizza;
    if (type.equals("cheese")) { pizza = new CheesePizza(); }
    else if (type.equals("greek")) { pizza = new GreekPizza(); }
    // ... more if-else blocks ...
    pizza.prepare();
    pizza.bake();
    return pizza;
}

This approach presents several critical challenges:

1. Violation of Single Responsibility Principle: This single method is now responsible for both deciding which pizza to create and managing the baking process.
2. Divergent Change: Every time the menu changes or the baking process is tweaked, this method must be modified, making it a “hot spot” for bugs.
3. Tight Coupling: The store is “intimately” aware of every concrete pizza class, making it impossible to add new regional styles without rewriting the store’s core logic.

Solution

The Factory Method Pattern solves this by defining an interface for creating an object but letting subclasses decide which class to instantiate. It effectively “defers” the responsibility of creation to subclasses.

In our PizzaStore example, we make the createPizza() method abstract within the base PizzaStore class. This abstract method is the “Factory Method”. We then create concrete subclasses like NYPizzaStore and ChicagoPizzaStore, each implementing createPizza() to return their specific regional variants.

The structure involves four key roles:

• Product: The common interface for the objects being created (e.g., Pizza).
• Concrete Product: The specific implementation (e.g., NYStyleCheesePizza).
• Creator: The abstract class that contains the high-level business logic (the “Template Method”) and declares the Factory Method.
• Concrete Creator: The subclass that implements the Factory Method to produce the actual product.

UML Role Diagram

UML Example Diagram

Sequence Diagram

Consequences

The primary benefit of this pattern is decoupling: the high-level “Creator” code is completely oblivious to which “Concrete Product” it is actually using. This allows the system to evolve independently; you can add a LAPizzaStore without touching a single line of code in the original PizzaStore base class.

However, there are trade-offs:

• Boilerplate Code: It requires creating many new classes (one for each product type and one for each creator type), which can increase the “static” complexity of the code.
• Program Comprehension: While it reduces long-term maintenance costs, it can make the initial learning curve steeper for new developers who aren’t familiar with the pattern.

Design Decisions

Abstract vs. Concrete Creator

• Abstract Creator (as shown above): Forces every subclass to implement the factory method. Maximum flexibility, but requires subclassing even for simple cases.
• Concrete Creator with default: The base creator provides a default product. Subclasses only override when they need a different product. Simpler, but may lead to confusion about when overriding is expected.

Parameterized Factory Method

Instead of having separate subclasses for each product, a single factory method takes a parameter (like a string or enum) to decide which product to create. This reduces the class count but violates the Open/Closed Principle—adding a new product requires modifying the factory method’s conditional logic.

Static Factory Method (Not GoF)

A common idiom—Loan.newTermLoan()—uses static methods on the product class itself to control creation. This is not the GoF Factory Method (which relies on subclass override), but is widely used in practice. It provides named constructors and can return cached instances or subtype variants.

Choosing the Right Creational Pattern

A common source of confusion is when to use Factory Method vs. the other creational patterns. The key discriminators are:

Pattern	Use When…	Key Characteristic
Factory Method	Only one type of product; subclasses decide which concrete type	Simplest; uses inheritance (subclass overrides a method)
Abstract Factory	A family of multiple related product types that must work together	Uses composition (client receives a factory object); highest extensibility for new families
Builder	Product has many parts with sequential construction; construction process itself varies	Separates the construction algorithm from the object representation

An important insight: factory methods often lurk inside Abstract Factories. Each creation method in an Abstract Factory (e.g., createDough(), createSauce()) is itself a factory method. The Abstract Factory defines the interface; the concrete factory subclasses implement each method—which is exactly the Factory Method pattern applied to multiple products.

Flashcards

Factory Method & Abstract Factory Flashcards

Key concepts and comparisons for creational design patterns.

What problem does Factory Method solve?

Decouples object creation from usage by letting subclasses decide which class to instantiate, avoiding conditional creation logic in the creator.

The creator defines an abstract createProduct() method; concrete creator subclasses implement it. Adding a new product variant means adding a new subclass, not modifying existing code.

What are the four roles in Factory Method?

Product (interface), Concrete Product (implementation), Creator (declares factory method + business logic), Concrete Creator (implements factory method).

The Creator contains the high-level workflow (a Template Method) that calls the factory method. Subclasses provide the concrete product without the Creator knowing which type it gets.

Factory Method vs. Abstract Factory: when to use which?

Factory Method: one product type, subclass decides. Abstract Factory: families of related products that must be used together.

Factory Method uses inheritance (subclass overrides). Abstract Factory uses composition (client receives a factory object). Factory methods lurk inside Abstract Factories.

What is a parameterized factory method?

A single factory method that takes a parameter (string/enum) to decide which product to create. Simpler but violates Open/Closed Principle.

Adding a new product type requires modifying the conditional logic inside the factory method, rather than adding a new subclass.

How does Factory Method relate to Abstract Factory?

Each creation method inside an Abstract Factory (e.g., createDough(), createSauce()) is itself a Factory Method.

Abstract Factory defines the interface; concrete factory subclasses implement each method — which is exactly Factory Method applied to multiple product types.

What is the ‘Rigid Interface’ drawback of Abstract Factory?

Adding a new product type to the family requires changing the interface and modifying every concrete factory.

The pattern has an asymmetry: adding new families is easy (pure addition), but adding new product types is hard (changes ripple). This is a fundamental design trade-off.

Abstract Factory uses __ ; Factory Method uses __.

Abstract Factory uses object composition (client receives a factory). Factory Method uses inheritance (subclass overrides a method).

This is the key structural difference. Composition provides more flexibility (factory can be swapped at runtime), while inheritance is simpler when the product hierarchy is straightforward.

Workout Complete!

Your Score: 0/7

Come back later to improve your recall!

Quiz

Factory Method & Abstract Factory Quiz

Test your understanding of creational patterns — when to use which, design decisions, and their relationships.

A PizzaStore uses a parameterized factory method: createPizza(String type) with an if/else chain to decide which pizza to create. A new pizza type (“BBQ Chicken”) must be added. What is the design problem?

Correct Answer:

Explanation

A parameterized factory method uses conditional logic to decide which product to create. Every new product type requires modifying this conditional — violating the Open/Closed Principle. The true Factory Method pattern solves this by using subclass override: each concrete creator implements createPizza() to return its specific product. Adding a new pizza type means adding a new subclass, not changing existing code.

A system needs to create families of related UI components (Button, TextField, Checkbox) that must be visually consistent — all from the same theme (Material, iOS, Windows). Which pattern is most appropriate?

Correct Answer:

Explanation

This is the classic Abstract Factory scenario: multiple product types (Button, TextField, Checkbox) that must belong to the same family (theme). Abstract Factory ensures that MaterialButton is always paired with MaterialTextField — preventing inconsistent combinations. Factory Method handles only one product type; Builder handles step-by-step construction.

“Factory Method uses classes to create; Abstract Factory uses objects.” What does this distinction mean structurally?

Correct Answer:

Explanation

This is a key structural distinction from the GoF. Factory Method uses inheritance: you extend a Creator class and override the factory method. Abstract Factory uses object composition: the client receives a factory object and calls its creation methods. Composition provides more runtime flexibility (factory objects can be swapped), while inheritance is simpler for single-product scenarios.

An Abstract Factory interface has 12 creation methods (one per product type). A new product type must be added. What is the consequence?

Correct Answer:

Explanation

This is the Rigid Interface drawback — the fundamental asymmetry of Abstract Factory. Adding new families (a new concrete factory + products) is a pure addition. But adding new product types requires changing the interface and modifying every concrete factory. At 12+ product types, this ripple effect becomes a serious maintenance burden.

Each method in a PizzaIngredientFactory — createDough(), createSauce(), createCheese() — is implemented differently by NYPizzaIngredientFactory and ChicagoPizzaIngredientFactory. What is the relationship between these creation methods and the Factory Method pattern?

Correct Answer:

Explanation

This is a crucial insight: factory methods lurk inside Abstract Factories. Each creation method in the Abstract Factory interface (e.g., createDough()) is declared abstract and overridden by concrete factory subclasses — which is exactly the Factory Method pattern. Abstract Factory orchestrates multiple Factory Methods to ensure family consistency.

Workout Complete!

Your Score: 0/5