Factory Method lets a class defer who gets created to its subclasses — so the client only ever talks to an interface, never a concrete type.
| Purpose | One method creates an object; subclasses decide the concrete class. |
| Key idea | "Defer instantiation to subclasses." |
| Creates | One product at a time. |
| Type | Class creational pattern. |
A class creational pattern used to encapsulate and defer object instantiation to derived classes. It defines an interface for creating an object, but lets subclasses decide which class to instantiate.
Creator declares createProduct() — it never says which Product. Each ConcreteCreator
fills that in.
Unlike Abstract Factory (many factory methods, many product families), Factory Method needs only one creational interface method for products that share one interface.
virtual in C++
code, is
abstract — that's your signal it's the Factory Method itself.
Two "creator" boxes on the left build; two "product" boxes on the right get built. Same shape, mirrored.
Scenario: An electronics store sells Standard and Advanced computers. The Standard Store can only build standard computers; the Advanced Store can only build advanced ones. Customers get a common interface — ask for a computer, get back its monitor/CPU/keyboard/cost — and new store categories (Workstation, Budget…) should slot in without touching existing code.
Declares the factory method createComputer() and a helper
displayComputer() that
calls it, then prints whatever it gets back.
StandardComputerStore / AdvancedComputerStore each override
createComputer() to return their own concrete Computer.
Computer types
possible without changing the client code — the creation logic lives only in
ComputerStore and its children.e.g. Computer, Parser, Channel.
Each realizes the interface. e.g. StandardComputer,
AdvancedComputer.
One abstract method that delegates product creation to derived classes. e.g.
ComputerStore.
e.g. StandardComputerStore, AdvancedComputerStore.
Wire each ConcreteCreator's factory method to return the matching ConcreteProduct.
main.
Same five ingredients, ordered the way you'd actually type the files.
The three pieces below are the same class split across declaration and two implementations — read them top to bottom and the pattern clicks.
Look for the virtual keyword — that marks the factory method.
Look for methods written in italics — same meaning, different notation.
Client code from product‑specific classes — the same code works with existing or new product classes.
Different developers can build different concrete creators/products at the same time.
Easier to reuse specific parts of the code in other systems.
Easier to maintain specific parts without touching the rest.
Improves testability — swap in a fake ConcreteCreator for tests.
| Aspect | Factory Method | Abstract Factory |
|---|---|---|
| Purpose | One factory method creates one product at a time. | Interface for creating families of related products. |
| Factory | One factory method (often parameterized); subclasses decide the product. | Factory interface with multiple factory methods (one per product type). |
| Products | Usually one hierarchy — e.g. Parser → PdfParser, WordParser. | Multiple related hierarchies — e.g. Button+Checkbox families for Windows/Mac. |
| Flexibility | Lightweight — one kind of product needed. | More complex — guarantees consistency across a family. |
| Client calls | A single method, e.g. createParser(). |
Multiple methods, e.g. createButton() + createCheckbox(),
always matched. |
Both are the exact same skeleton as the Computer Store — swap the nouns and the answer barely changes. That repetition is the exam prep.
Abstract DocumentReader declares one overridable method that returns the
Parser
to use. Each concrete reader (PdfReader, WordReader,
ExcelReader)
overrides it to return its own parser. Adding PowerPoint support = add one new reader subclass, zero
changes
to existing client code.
Answer: Factory Method — one product family (Parser), one factory method, subclasses decide.
Abstract NotificationSender implements the fixed workflow — validate →
createChannel()
→ send. Each concrete sender (EmailSender, SmsSender,
PushSender) overrides
createChannel() to return its own Channel. Adding WhatsApp = one new
sender + one new channel class.
Answer: Factory Method again — same shape as Scenario A, different domain.
"The parent declares the recipe. The child decides the ingredient."
CCPP — Creator, ConcreteCreator, Product, ConcreteProduct.
virtual in code = italics in UML.
PCFCA — Product, Concrete products, Factory, Concrete factories, Associate.
SERMT — Separates, Efficient, Reuse, Maintain, Testability.
One product/one method → Factory Method. Many products/many methods/one family → Abstract Factory.