Factory Method

When you write new ConcreteClass() directly, a hard dependency on that class is baked into your code. It is fine at first, but the moment you need a different implementation serving the same role, problems start. For example, you begin with new EmailNotifier() for a notification feature, and later SMS and push notifications are added. Now that creation code is scattered throughout the codebase and every occurrence must be found and updated. Using if-else or switch to branch by type means every new type adds another branch, and as branches accumulate the blast radius of changes grows uncontrollably. The core issue is a coupling structure where changing 'which object to create' forces changes on the code that uses the object.

In the early 1990s, as object-oriented programming took hold across the industry, building reusable frameworks was a key challenge. A framework needed to define the overall flow while letting users fill in the specifics. But calling new directly inside the framework locked it to a particular implementation, making it hard for users to substitute their own objects. GoF solved this with the idea: 'extract creation into a method and let subclasses override it.' The framework calls only the abstract method; concrete creation is handled by whoever extends the framework. This approach was subsequently absorbed into the standard libraries and frameworks of nearly every object-oriented language, including Java, C#, and Python.

The heart of Factory Method is pulling the act of creation into a separate method. First, there is the Product interface -- the contract that all created objects share. The client depends on this interface alone. Next, the Creator class declares a factory method such as createProduct(). It specifies only that the return type is the Product interface; what gets created inside is left open. Finally, ConcreteCreator overrides this method to instantiate a specific ConcreteProduct. ConcreteCreatorA returns ProductA; ConcreteCreatorB returns ProductB. Client code receives a Creator type and calls createProduct(). Different ConcreteCreators produce different Products, but the client never needs to know the difference.

Factory Method and Abstract Factory both abstract object creation, but they differ in scale. Factory Method is a single method creating a single object, while Abstract Factory is an interface for creating an entire family of related objects at once. If you only need to swap out one product per platform, Factory Method fits; if you need to swap buttons, text fields, and checkboxes as a matched set per platform, Abstract Factory is the natural choice. Factory Method is also easily confused with Simple Factory. Simple Factory is just a static method that branches with if-else to create objects -- more of an idiom than a design pattern. Factory Method uses inheritance and overriding to delegate creation, so adding a new type does not require modifying existing code.

Factory Method becomes useful when objects with the same role must be created differently depending on context, and those branches are starting to spread. Choosing whether logs go to a file or the console, notifications go by email or push, or payments go by card or bank transfer are typical examples. Pulling creation into one place means adding a new implementation touches less of the calling code. It also appears frequently in frameworks and libraries. When the framework owns the flow but wants to leave the concrete object choice to the user, Factory Method makes that extension point explicit. If there is only one type and little chance it will change, though, Factory Method is just extra abstraction. It adds classes and makes the code harder to trace. The pattern pays off only on axes where change is real.