Factory

Design PrinciplesMid

The Question

What is the Factory pattern and when would you use it?

What a Strong Answer Covers

• decouples creation
• "returns subclass based on input

Senior-Level Answer

The Factory pattern is a creational design pattern that encapsulates object creation logic behind an interface, so callers don't need to know which concrete class they're instantiating. The term covers two related patterns: Factory Method (a method that subclasses override to produce objects) and Abstract Factory (an interface for creating families of related objects).

The core problem it solves: when you write `new ConcreteClass()` throughout a codebase, you've hardcoded a dependency on that specific class. If the class changes, or you need to swap in a different implementation (different database driver, different payment provider, different notification channel), you must find and change every instantiation site. A factory centralizes that decision.

A practical example: an application supports multiple notification channels — email, SMS, Slack. Rather than scattering `if channel == 'email': return EmailNotifier()` logic throughout the codebase, a `NotifierFactory.create(channel)` method owns that conditional. Callers only work with the `Notifier` interface. Adding push notifications means touching one file.

When to use it: when the type to create is determined at runtime (from config, user input, or a strategy name); when you want to isolate object construction from business logic for testability; when constructing an object is complex enough that you want to hide the details; and when you anticipate needing to swap implementations. It pairs naturally with dependency injection — factories are often what DI containers call to build objects.

Abstract Factory extends this: instead of creating one type of object, it creates a family. A UI toolkit factory might produce buttons, checkboxes, and dialogs that all share a visual theme. Swapping the factory swaps the entire family consistently.

A Python-idiomatic approach often skips the class entirely and uses a dictionary mapping strings to classes, or a registration pattern where subclasses register themselves. This achieves the same decoupling without ceremony.

The tradeoff: factories add a layer of indirection. For simple, stable object creation that will never change, they add complexity without value. Use them when variability is real, not hypothetical.

What Separates a 2/3 from a 3/3

Common Mistakes

• Defining Factory as just 'a method that creates objects' without explaining the decoupling purpose — misses the point of the pattern.
• Confusing Factory Method with Abstract Factory — these solve related but distinct problems.
• Overrecommending Factory for every object creation scenario without noting the indirection cost.
• Not connecting Factory to testability — factories make it easy to inject test doubles by swapping the factory.

Follow-Up Questions

• How does the Factory pattern improve testability? — You can substitute a TestFactory that returns mocks or stubs, without changing any caller code — the factory is the seam.
• What is the difference between Factory Method and Abstract Factory? — Factory Method is a single method that subclasses override to create one type. Abstract Factory is an interface for creating a family of related objects.
• How would you implement an extensible factory in Python without if/elif chains? — Registry pattern: a dict mapping string keys to classes; subclasses self-register on definition using a class decorator or metaclass.
• When would you prefer a Factory over a DI container? — When creation logic is dynamic (depends on runtime data), when you need to create multiple instances over the lifetime of the app, or when the framework overhead isn't warranted.

Related Questions

• Singleton
• Strategy
• Observer
• IoC / Dependency Injection
• High Cohesion / Loose Coupling