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.

The typical signal for Factory Method is code that needs to create objects serving the same role but with different implementations depending on the situation. Whether to write logs to a file or console, send notifications via email or push, process payments by card or bank transfer -- if that branching logic is scattered across multiple locations, Factory Method is worth considering to consolidate creation points. It is also useful when designing frameworks or libraries. When a framework defines the overall flow but the concrete objects used within that flow should be determined by the consumer, placing a Factory Method creates a clear extension point. However, if there is only one type and it is unlikely to change, Factory Method is over-abstraction. It just adds unnecessary classes and makes the code harder to follow. The key is to apply it only to the axes where change actually occurs.