Abstract Factory Pattern
Abstract Factory: start from the problem
See the responsibilities
An application supports two interface styles. Each needs a matching button and checkbox. Selecting those objects independently can create a mixed interface, even though every object works by itself.
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 Abstract Factory 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
An Abstract Factory exposes operations for creating a related family of products. Each concrete factory produces compatible members of that family. The caller selects the family once and then asks that factory for the products it needs.
The example chooses a compact interface factory. Both its button and checkbox follow the same style. Client code depends on the creation contract rather than naming every concrete widget class.
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
const compactFactory = {
button: () => ({render: () => 'compact button'}),
checkbox: () => ({render: () => 'compact checkbox'})
};
function renderSettings(factory) {
return [factory.button().render(), factory.checkbox().render()].join(' | ');
}
console.log(renderSettings(compactFactory));Expected output
compact button | compact checkboxChoose 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 products must be selected together, such as related UI components or a supported storage-driver family with matching readers and writers.
Adding a new product kind can require updating every factory. Too many family interfaces can obscure a configuration that only needs one product. Compatibility must be tested, not inferred from factory membership alone.
Distinguish the neighbouring patterns
Factory Method changes one creation step through a creator extension. Builder assembles one result through steps; it does not necessarily choose a family of related products.
Follow Factory Method’s creation extension, Builder’s step-by-step construction, Bridge’s independent dimensions to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Abstract Factory, 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 Bridge’s independent dimensions.
Reaching the recap and completing the quizzes are separate milestones.