Factory Method Pattern: Letting a Subclass Decide Which Object to Create

The Factory Method pattern defines a method for creating an object in a base class, and lets each subclass override that method to choose the object's class. The code that uses the object is written once, in the base class, and never names a concrete class. This card covers the problem the pattern solves, its intent, and when it is and is not worth using.

The problem is that new EmailSender() ties the line it is on to EmailSender. If an order system notifies customers by email, and the business later wants SMS for some customers, every method that creates a sender has to change. The steps around the creation, building the message and recording that it was sent, are the same for both channels. Only the class differs.

class OrderNotifier:
    def notify_shipped(self, order_id):
        sender = EmailSender()
        sender.send(f"Order {order_id} has shipped.")

class OrderNotifier(ABC):
    @abstractmethod
    def create_sender(self) -> Sender: ...

    def notify_shipped(self, order_id):
        sender = self.create_sender()
        sender.send(f"Order {order_id} has shipped.")

The Gang of Four state the intent as: define an interface for creating an object, but let subclasses decide which class to instantiate. The method that does the creating is the factory method, and the class that declares it is the creator.

Think of a restaurant franchise. Head office writes how every order is served, from greeting to bill, and each branch decides which local dish to cook. The analogy breaks in one place: a branch can change its menu whenever it likes, while each subclass is fixed to the one class its factory method returns.

Factory Method is one of five creational patterns, the family that controls how objects are created.