Factory Method Pattern
Factory Method: start from the problem
See the responsibilities
A report exporter knows the order of work: obtain a writer, format the report and deliver it. Different exporters need different writers. Repeating the complete export workflow in every variant makes a later workflow change easy to miss.
This is a creational pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Factory Method addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Factory Method gives a creator a method for obtaining a product. A specialized creator overrides that method while the surrounding workflow uses the product through a shared contract. The pattern’s important boundary is the overridable creation step, not merely a function named create.
In our example, Exporter owns exportReport, while CsvExporter chooses a writer that understands CSV. A new creator can choose another writer without rewriting the workflow. The product must still supply the operations the creator expects.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
class Exporter {
createWriter() { throw new Error('Choose a writer'); }
exportReport(text) { return this.createWriter().write(text); }
}
class CsvExporter extends Exporter {
createWriter() { return {write: text => 'CSV: ' + text}; }
}
console.log(new CsvExporter().exportReport('sales'));Expected output
CSV: salesChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when a stable workflow needs a creation extension point, such as an export pipeline with supported writer types.
Extra creator subclasses can be unnecessary when a simple injected writer or a small constructor function is sufficient. Name the lifetime and ownership of created products rather than quietly creating expensive connections per request.
Distinguish the neighbouring patterns
Abstract Factory creates a compatible family of products. Factory Method supplies an extension point for one product creation step. Strategy usually changes the behaviour used by an existing object.
Follow Abstract Factory for matching product families, Strategy for changing behaviour, the boundary between system and code design to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Factory Method, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside the boundary between system and code design.
Reaching the recap and completing the quizzes are separate milestones.