design-pattern-abstract-factory

Skill: Abstract Factory

Intent

Provide a single factory interface for creating a family of related products so clients can switch whole families atomically while preserving compatibility between produced objects.

Applicability Signals

• Signal 1: The system constructs multiple related object types that must remain compatible.
• Signal 2: Environment/brand/platform modes require swapping an entire object family together.
• Signal 3: Client code currently mixes concrete class names across product categories, causing drift and mismatch bugs.

Contraindications

• Case 1: Only one product type exists; factory families add unnecessary indirection.
• Case 2: Product compatibility constraints are weak and combinations are freely mixed.
• Case 3: The object graph is small and unlikely to vary by family.

Decision Heuristics

• If you need a coherent suite of products selected as one unit, prefer Abstract Factory.
• If only a single product creation point varies, Factory Method may be simpler.
• Decision anti-bias note: avoid creating family abstractions before concrete compatibility constraints are real.

Implementation Checklist

• Define abstract product interfaces for each product role.
• Define abstract factory interface with one method per product role.
• Implement concrete factories that produce internally compatible products.
• Inject factory into client composition root rather than hardcoding concrete families.
• Add tests validating intra-family compatibility and safe family swap.

Misuse Checks

• Misuse 1: Client downcasts products to concrete types → Remediation: expose required behavior via abstract product interfaces.
• Misuse 2: Concrete factories mix products from different families → Remediation: enforce family invariants in factory tests.
• Misuse 3: Too many unused product methods on abstract factory → Remediation: split factories by bounded context.

Verification Rubric

• Correctness:
  • Baseline factory produces all required product roles.
  • Switching to another factory swaps full family without client rewrites.
• Design quality:
  • Product and factory contracts are cohesive and minimal.
  • Family boundaries are explicit and enforced.
• Regression safety:
  • Tests cover one family baseline and one alternate family with compatibility assertions.

Language-Specific Adaptations (Optional)

• TypeScript: encode product-family contracts with interfaces and constructor injection.
• Python: use ABCs/protocols; dependency injection container can select concrete factory by runtime profile.
• Go: keep abstract factory as interface; wire concrete implementation at composition root.

Related Patterns (Optional)

• Factory Method: can be used inside concrete abstract factories for finer-grained creation hooks.
• Builder: use when construction is stepwise/ordered instead of family-based.

Attribution & Sources

• Source Site: Refactoring.Guru
• Source URLs:
  • https://refactoring.guru/design-patterns/abstract-factory
  • https://refactoring.guru/design-patterns
• Derivation Note: Concepts derived from referenced sources; explanatory wording rewritten for this repository.
• Policy Note: This artifact intentionally includes no direct quotes and no Refactoring.Guru images.