Factory Method Pattern
Delegate the creation of a product to creator implementations so client code depends on abstractions rather than concrete constructors.
Concept Overview
Factory Method is a creational design pattern that defines an interface for creating an object while allowing subclasses or concrete creators to decide which product implementation is instantiated. The goal is to separate the code that uses a product from the concrete class-selection decision. It is useful when product variation is meaningful and likely to grow, not simply as a wrapper around every constructor call.
1. The problem: client code knows too much about construction
Suppose an application directly creates EmailSender, SmsSender or PushSender objects throughout the codebase. Every caller that chooses a concrete class becomes coupled to that implementation. Adding a new notification channel may require editing many client classes. A factory method moves the construction decision behind a creator abstraction so the client works with a common product interface.
2. Participants and collaboration
The Product defines the common interface. Concrete Products implement it. The Creator declares the factory method and usually contains business logic that works with the Product abstraction. Concrete Creators override the factory method to return a particular Concrete Product. This preserves the relationship between creation and use without forcing every client to depend on each implementation class.
interface Notification {
void send(String message);
}
final class EmailNotification implements Notification {
public void send(String message) { /* send email */ }
}
abstract class NotificationCreator {
protected abstract Notification createNotification();
public void notifyUser(String message) {
Notification notification = createNotification();
notification.send(message);
}
}
final class EmailCreator extends NotificationCreator {
protected Notification createNotification() {
return new EmailNotification();
}
}3. Why polymorphism matters
The creator's business operation calls the factory method and then uses the returned Product through its interface. The operation does not need to know whether it received an email, SMS or push implementation. A different creator supplies a different product. This is an application of programming to an abstraction: callers depend on the stable contract while concrete construction varies behind it.
4. Factory Method versus a simple static factory
A static factory method is a convenient named method that returns an object; it is not automatically the GoF Factory Method pattern. The classic pattern relies on creator polymorphism so subclasses or concrete creators determine which product gets created. Static factories can still be excellent design choices when that variation does not need a hierarchy. Choose the least complex mechanism that solves the actual construction problem.
5. When to use it and when not to
Use Factory Method when a framework or application has a stable workflow but needs different product implementations, such as exporters, notification channels or document parsers. Avoid it when there are only one or two simple constructions and no meaningful extension point. An unnecessary creator hierarchy can make a small program harder to follow than direct construction.
Key Takeaways
- ✓Factory Method delegates product selection to creator implementations.
- ✓Clients should use the product abstraction rather than concrete product classes.
- ✓A static factory method is not automatically the GoF Factory Method pattern.
- ✓Use the pattern when product variation justifies the additional structure.