Factory Method Trade-offs and When to Use

When to Use Factory Method:
First, use Factory Method when a class cannot anticipate the type of objects it needs to create. Second, apply it when you want subclasses to specify the objects they create. Third, employ it when you need to delegate responsibility to helper subclasses and want to localize the knowledge of which helper subclass is the delegate. Fourth, use it when you want to provide hooks for extending object creation behavior in subclasses.
Simple Factory
Single factory class with conditional logic (if/switch). All creation logic centralized. Violates Open/Closed Principle when adding new types.
↔
Factory Method
Uses inheritance. Each subclass creates its own product type. Adding new types means adding new subclasses without modifying existing code.
Factory Method vs Abstract Factory:
Factory Method creates one product and uses inheritance (class-based). Abstract Factory creates families of related products and uses composition (object-based). If you only need to create one type of object with variations, Factory Method is appropriate. If you need to create multiple related objects that must be compatible (like UI components for Windows vs Mac), Abstract Factory is better suited.
Trade-offs:
Advantages:
First, eliminates binding of application-specific classes into your code. Second, provides hooks for subclasses through factory method. Third, connects parallel class hierarchies (Creator and Product). Fourth, adheres to Single Responsibility Principle by separating product creation from usage.
Disadvantages:
First, requires creating a new subclass just to change the product type, increasing class count. Second, can be overkill if you only have one product type with no variation expected. Third, makes code harder to understand for simple scenarios where direct instantiation is clearer. Fourth, forces parallel hierarchies which adds structural overhead.
Interview Tip: When asked "Why not just use new ConcreteProduct()?", explain that direct instantiation couples code to concrete classes. Factory Method allows changing product types by changing the creator subclass, not by modifying calling code.
When Factory Method is Overkill:
First, when you have only one product type and no variation is anticipated, direct instantiation is simpler. Second, when product creation has no complex logic (just calling a constructor), a factory adds unnecessary indirection. Third, when the product types are known and fixed at compile time with no extension expected. In these cases, either direct instantiation or a Simple Factory is more appropriate.
Real Interview Scenario:
If asked to design a notification system, you might use Factory Method if different notification types (Email, SMS, Push) have different creation and sending logic. However, if all notifications are created the same way and only differ in message content, a Simple Factory or direct instantiation with a strategy for sending would be cleaner.

💡 Key Takeaways

✓Use Factory Method when subclasses need to decide which class to instantiate

✓Prefer Simple Factory when creation logic is simple and centralized

✓Choose Abstract Factory when you need families of related products

✓Factory Method is overkill if only one product type exists with no variation expected

📌 Examples

1Use: Document editor with PDF, Word, HTML formats requiring different parsers

2Overkill: Configuration reader that always returns the same Config object type

← Back to Factory Method Pattern Overview