Abstract Factory Pattern
Also Known As
abstract factory
family factory
TL;DR
Creates families of related objects ensuring they are used together consistently without mixing implementations.
Explanation
The Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. Each concrete factory produces a consistent set of products (e.g., StripeGateway, StripeRequest, StripeResponse). This ensures that objects designed to work together are never mixed with incompatible ones. It is commonly used when systems must support multiple interchangeable configurations (e.g., payment providers, UI themes, database drivers). Unlike Factory Method, which creates a single product, Abstract Factory guarantees consistency across a full product family.
Common Misconception
✗ Abstract Factory and Factory Method are interchangeable. Factory Method creates a single product, while Abstract Factory ensures a consistent family of related products is created together.
Why It Matters
Without Abstract Factory, systems can accidentally mix incompatible objects from different providers — these errors often compile but fail at runtime and are hard to trace.
Common Mistakes
- Using Abstract Factory when only one product varies — adds unnecessary complexity.
- Creating factories that return unrelated objects — defeats the purpose of product families.
- Exposing concrete factories directly instead of injecting abstractions.
- Mixing factory-created objects with manually instantiated ones.
Avoid When
- Only one product type varies — use Factory Method instead.
- Products are independent and do not need to be used together.
- System has a single fixed implementation with no variation.
- The abstraction adds more complexity than the variation justifies.
When To Use
- Multiple related objects must always be used together.
- System must support interchangeable product families (e.g., providers, themes).
- You want to enforce compatibility between created objects.
- Configuration should swap entire implementations, not individual classes.
Code Examples
💡 Note
All objects are created via the same factory, guaranteeing they belong to the same compatible family.
✗ Vulnerable
// ❌ Mixing incompatible product families
$gateway = new StripeGateway();
$request = new BraintreePaymentRequest(); // runtime mismatch
✓ Fixed
interface PaymentFactory {
public function createGateway(): GatewayInterface;
public function createRequest(Money $amount): RequestInterface;
public function createResponse(array $data): ResponseInterface;
}
final class StripeFactory implements PaymentFactory {
public function createGateway(): GatewayInterface {
return new StripeGateway();
}
public function createRequest(Money $amount): RequestInterface {
return new StripeRequest($amount);
}
public function createResponse(array $data): ResponseInterface {
return new StripeResponse($data);
}
}
// Usage
function processPayment(PaymentFactory $factory, Money $amount) {
$gateway = $factory->createGateway();
$request = $factory->createRequest($amount);
$rawResponse = $gateway->send($request);
return $factory->createResponse($rawResponse);
}
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
16 Mar 2026
Edited
27 Mar 2026
Views
57
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Perplexity 13
Amazonbot 12
ChatGPT 11
Unknown AI 3
Google 3
Majestic 1
Ahrefs 1
SEMrush 1
Also referenced
How they use it
crawler 43
crawler_json 2
Related categories
⚡
DEV INTEL
Tools & Severity
🟢 Low
⚙ Fix effort: Medium
⚡ Quick Fix
If multiple related objects must always be used together, introduce an Abstract Factory and inject it instead of instantiating objects directly.
📦 Applies To
PHP 5.0+
web
cli
queue-worker
🔍 Detection Hints
new .*Gateway && new .*Request from different providers OR switch creating multiple related objects
Auto-detectable:
✗ No
phpstan
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: Medium
Context: Class
Tests: Update