What Is the Abstract Factory Pattern?
Abstract Factory is a creational pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes. Rather than a single factory method producing one product, an AbstractFactory interface declares multiple creation methods — one per product type in the family — and each concrete factory implementation produces one internally consistent set of those products. Client code depends only on the abstract factory and abstract product interfaces, so it can swap an entire family of objects simply by swapping which concrete factory it uses.
Cricket analogy: A cricket equipment abstract factory guarantees that whichever brand family you pick — say a full Gray-Nicolls kit or a full SG kit — the bat, pads, and gloves you get all match in weight profile and grip style, rather than mixing incompatible brands.
Structure and Implementation
The AbstractFactory interface declares one creation method per product type — for a UI toolkit this might be createButton() and createCheckbox(). Each ConcreteFactory (say, WindowsFactory or MacFactory) implements every one of those methods, returning platform-specific implementations of the abstract Button and Checkbox interfaces. Client code receives one factory instance and calls its methods without ever referencing WindowsButton or MacButton directly, so switching platforms is a matter of swapping which concrete factory gets instantiated at startup.
Cricket analogy: The AbstractKitFactory interface declares createBat() and createPads() as two related creation methods; the GrayNicollsFactory implements both to return GrayNicollsBat and GrayNicollsPads, while the SGFactory implements both to return SGBat and SGPads, keeping each brand's family internally consistent.
interface GUIFactory {
createButton(): Button;
createCheckbox(): Checkbox;
}
class MacFactory implements GUIFactory {
createButton(): Button { return new MacButton(); }
createCheckbox(): Checkbox { return new MacCheckbox(); }
}
class WindowsFactory implements GUIFactory {
createButton(): Button { return new WindowsButton(); }
createCheckbox(): Checkbox { return new WindowsCheckbox(); }
}
function renderUI(factory: GUIFactory) {
const button = factory.createButton();
const checkbox = factory.createCheckbox();
button.paint();
checkbox.paint();
}Ensuring Family Consistency
The key structural guarantee of Abstract Factory is that because client code obtains all its products through a single chosen factory instance, it structurally cannot end up mixing products from incompatible families. There's no code path where a MacButton accidentally pairs with a WindowsCheckbox, because both come from whichever one factory the client was handed — the compatibility guarantee is baked into the design rather than enforced by runtime checks.
Cricket analogy: Because the factory bundles bat and pads together, a batsman can never end up with a GrayNicolls bat's heavier swing weight paired with SG's stiffer padding — the abstract factory's guarantee prevents that mismatched, awkward combination from ever compiling into a real setup.
The key promise of Abstract Factory is consistency: every product returned by one concrete factory instance is guaranteed to belong to the same family, so client code never has to check compatibility between the button and checkbox it received.
Trade-offs and When to Use
Abstract Factory makes adding a new family (e.g., a new theme or platform) cheap — you just add one new concrete factory implementing the existing interface. But adding a brand-new product type (e.g., a slider control alongside buttons and checkboxes) is expensive: it requires changing the AbstractFactory interface itself and then updating every single concrete factory to implement the new method, which can mean touching many files for what feels like one small feature. This trade-off is the opposite of Factory Method, which makes adding new product types cheap but doesn't organize products into consistent families.
Cricket analogy: Introducing a new product like createHelmet() means editing the AbstractKitFactory interface and then every single brand's factory — GrayNicolls, SG, and any others — making it easy to add a new brand family but costly to add a new equipment category.
Adding a brand-new product type (not just a new family) requires updating the AbstractFactory interface and every concrete factory implementing it — this can mean touching many classes for what seems like a small feature addition.
- Abstract Factory provides an interface for creating families of related objects without specifying their concrete classes.
- Each concrete factory implementation produces one internally consistent family of products.
- Client code depends only on the abstract factory and abstract product interfaces, never concrete classes.
- It guarantees products from the same factory are compatible, preventing accidental mixing across families.
- Adding a new family (e.g., a new theme) means adding one new concrete factory — easy and open/closed-compliant.
- Adding a new product type (e.g., a new kind of widget) requires changing the interface and every concrete factory — costly.
- Commonly used for cross-platform UI toolkits, theming systems, and configuration bundles.
Practice what you learned
1. What is the defining goal of the Abstract Factory pattern?
2. What guarantee does a concrete Abstract Factory implementation provide?
3. What is a notable trade-off of the Abstract Factory pattern?
4. How does Abstract Factory relate to Factory Method?
5. Which scenario best fits Abstract Factory?
Was this page helpful?
You May Also Like
Factory Method Pattern
Defines an interface for creating an object but lets subclasses decide which concrete class to instantiate.
Builder Pattern
Separates the construction of a complex object from its representation, building it step by step.
Singleton Pattern
Ensures a class has only one instance and provides a single global point of access to it.
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