Requests shipment processing
Backend & Runtime / Knowledge library
Factory Method Pattern
Defers concrete object creation behind an overridable creation operation
Why learn Factory Method Pattern?
It decouples callers from the classes they instantiate
The problem it solves
It allows product types to vary without rewriting client logic
Where it came from
Factory Method Pattern is a software design pattern that defers concrete object creation behind an overridable creation operation. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Factory Method Pattern and distinguish it from a neighboring concept.
- Choose a realistic task where Factory Method Pattern is appropriate.
- Identify a failure mode caused by misusing Factory Method Pattern.
- Interpret a small design or result involving Factory Method Pattern.
- Explain one tradeoff or limitation of Factory Method Pattern.
Documentation and sources
- Patterns of Enterprise Application Architecture (martinfowler.com)
Connect the ideas
Explore next
Real World Example
Logistics Route Orchestration
Global logistics providers managing multi-modal freight shipments.
The business problem
Hard-coded instantiation of transport handlers leads to rigid systems where adding a new transport mode, such as autonomous drone delivery, requires modifying existing core business logic, increasing the risk of regression errors.
How this topic solves it
The Factory Method Pattern decouples the client code from the concrete transport classes by defining an abstract creation method in a base orchestrator. Subclasses override this method to instantiate the specific transport handler required for the shipment type, allowing the system to scale without altering the core orchestration logic.
- Define an abstract base class for the logistics orchestrator containing a deferred creation method.
- Implement concrete creator subclasses for each transport mode, such as SeaLogistics or AirLogistics.
- Define a common interface for all transport handlers to ensure consistent behavior.
- Configure the client to use the abstract orchestrator, which delegates object creation to the specific subclass implementation.
Shows how the client interacts with the abstract orchestrator to receive a concrete transport handler.
Defines factory method
Implements creation logic
Executes delivery
- Client → invokes → AbstractOrchestrator
- AbstractOrchestrator → overridden by → ConcreteCreator
- ConcreteCreator → instantiates → TransportHandler
Expected business outcome
The system achieves high extensibility, allowing developers to introduce new transport modes by adding new classes rather than modifying existing, tested orchestration code.
Limitations and checks
The pattern introduces a proliferation of subclasses, which can increase architectural complexity. To check if this is becoming a burden, monitor the ratio of creator subclasses to actual business logic; if the number of creators grows disproportionately to the core functionality, consider consolidating logic or using a registry-based approach.