What Is the Factory Method Pattern?
Factory Method is a creational pattern that defines a method for creating an object, but lets subclasses decide which concrete class actually gets instantiated. Instead of a client hardcoding a call to a concrete constructor, an abstract Creator class declares a factory method (often abstract or with a default implementation), and each ConcreteCreator subclass overrides it to return a specific ConcreteProduct. Client code only interacts with the abstract Creator and Product interfaces, so it never needs to know which exact class was created.
Cricket analogy: A national cricket board defines a standard 'select an opening pair' procedure, but leaves the actual choice of which two batsmen to send in up to each match's team captain — that's the factory method deciding the concrete instance.
Structure and Implementation
The structure has four moving parts: an abstract Product interface, one or more ConcreteProduct classes implementing it, an abstract Creator class declaring the factory method, and one or more ConcreteCreator subclasses overriding that method to return a specific ConcreteProduct. The Creator often contains other business logic that calls the factory method internally, so overriding just the creation step is enough to change behavior throughout the rest of the class without duplicating any of that surrounding logic.
Cricket analogy: The abstract 'MatchOfficial' role defines createUmpire() as the factory method, and the ODIMatchOfficial subclass overrides it to instantiate an ODIUmpire while the T20MatchOfficial subclass instantiates a T20Umpire, both implementing the same Umpire interface.
abstract class DocumentCreator {
abstract createDocument(): Document;
render(): string {
const doc = this.createDocument();
return doc.export();
}
}
class PDFCreator extends DocumentCreator {
createDocument(): Document {
return new PDFDocument();
}
}
class WordCreator extends DocumentCreator {
createDocument(): Document {
return new WordDocument();
}
}Factory Method vs Simple Factory vs Abstract Factory
A 'simple factory' is not one of the classic Gang of Four patterns — it's usually just a single static helper method with a switch or if-else chain that dispenses different object types from one place. Factory Method instead uses inheritance and polymorphism: each subclass overrides the creation step itself. Abstract Factory goes a level further, providing an interface for creating whole families of related objects together, guaranteeing the returned objects are compatible with each other, whereas Factory Method concerns itself with producing just one product type per call.
Cricket analogy: A simple factory is like one selector who reads a rulebook and hands out any format's kit from a single desk; a factory method is like each format's own dedicated selector (Test, ODI, T20) deciding their own squad through inheritance rather than one central desk.
Don't confuse a 'simple factory' (a single static method with a switch/if-else dispensing objects) with the Factory Method pattern (which uses subclassing and polymorphism to let each creator decide what to instantiate) or Abstract Factory (which produces whole families of related objects).
Benefits and Trade-offs
Factory Method's biggest benefit is honoring the open/closed principle: adding a new product variant only requires writing a new Creator/Product subclass pair, without touching any existing, tested code. The trade-off is structural complexity — every new product type introduces a new class, and the codebase ends up maintaining a parallel hierarchy of creators that mirrors the hierarchy of products, which can feel like overkill for systems with only a couple of stable variants.
Cricket analogy: Adding a new format like The Hundred only requires a new HundredMatchOfficial subclass without touching existing ODI or T20 officiating code, following the open/closed principle — but the board now maintains a parallel hierarchy of officials matching its hierarchy of formats.
Overusing Factory Method for cases with only one or two product variants that rarely change adds an unnecessary layer of abstract classes and subclasses — a simple factory function or even a direct constructor call is often clearer.
- Factory Method defines a creation step as a method that subclasses override to decide which concrete class gets instantiated.
- The abstract Creator class declares the factory method; ConcreteCreator subclasses implement it to return a specific ConcreteProduct.
- All products returned by different concrete creators implement a common Product interface.
- It differs from a simple factory (one static method) by using inheritance and polymorphism instead of conditional logic.
- It differs from Abstract Factory, which produces whole families of related products rather than a single product type.
- Adding a new product type only requires a new Creator subclass, honoring the open/closed principle.
- Trade-off: introduces a parallel class hierarchy of creators that mirrors the product hierarchy.
Practice what you learned
1. What does the Factory Method pattern let subclasses do?
2. How does Factory Method primarily achieve its flexibility?
3. What distinguishes Factory Method from a 'simple factory'?
4. What is a trade-off of using Factory Method extensively?
5. Which principle does Factory Method support by letting you add new product types via new subclasses?
Was this page helpful?
You May Also Like
Abstract Factory Pattern
Provides an interface for creating families of related objects without specifying their concrete classes.
Builder Pattern
Separates the construction of a complex object from its representation, building it step by step.
Prototype Pattern
Creates new objects by cloning an existing, pre-configured instance instead of constructing from scratch.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics