Factory Design Pattern¶
Create the right object at the right time without scattering construction logic everywhere.
The Factory Pattern is useful when your code should ask for a capability, not micromanage how every concrete object gets built.
Business Framing¶
Imagine a business platform that can send:
email notifications
SMS alerts
Slack messages
If every module builds those objects manually, your codebase quickly fills with repeated setup logic. A factory gives one place where creation decisions live.
Visual Intuition¶
When to Use Factory¶
| Situation | Why factory helps |
|---|---|
| Many related objects share an interface | Creation stays centralized |
| New object types appear over time | Changes stay in one place |
| Constructors need setup rules | Callers stay clean |
| You want readable calling code | Business logic stays focused on outcomes |
Worked Example: Notification Factory¶
Why this is better than repeated object creation
The caller no longer needs to know which class to instantiate. It just requests a channel and gets a ready object back.
Strengths and Tradeoffs¶
| Strength | Tradeoff |
|---|---|
| Cleaner calling code | One more abstraction layer |
| Easier to add new product types | Factory can become bloated if unmanaged |
| Good for testing and dependency swaps | Not every object needs a factory |
Common Anti-Pattern¶
Do not create a factory just to wrap a single constructor with no business value.
Bad idea:
UserFactory.create_user(name)that only returnsUser(name)and adds no rules
Good idea:
a factory that selects a notifier, parser, exporter, or storage backend based on context
Mini Quiz¶
What problem does Factory solve better than repeated
if/elifobject creation in many files?What is the main output of a factory method?
When should you avoid introducing a factory?
Answer Check
Scattered construction logic
A correctly configured object implementing a known interface
When object creation is trivial and unlikely to change
Your Turn¶
Design a ReportFactory that can return PDFReport, ExcelReport, or DashboardReport.
One Possible Approach
Create one factory method such as ReportFactory.create(format_name) and keep all report selection logic there instead of spreading it across controllers, scripts, and APIs.
Interactive Code¶
What to notice
The caller still asks only for a channel. The creation logic becomes easier to extend because new product types can be registered in one place.
Guided Practice¶
What is the clearest sign that a Factory pattern is worth introducing?¶
Exercises¶
Add a
TeamsNotifierorWhatsAppNotifierto the factory without changing any caller code.Build a
StorageFactorythat returns a CSV, database, or API storage client.
Exercise hint
Start by deciding on a tiny interface such as save(data), then return different concrete objects from one centralized creation method.
Key Takeaway¶
Factory is not about hiding code. It is about putting object-creation decisions in one clean, reusable place.
Quick MCQ — Factory registry advantage¶
A) It makes objects slower to create
B) It centralizes registration so new types can be added without changing callers
C) It forces all callers to import all concrete classes
Correct: B — registries let you add new types without changing callers.