Factory Method

The Factory Method pattern defines a method for creating objects, but lets subclasses override that method to change the class of the objects that will be created. The calling code works with a product through an abstract interface and never names a concrete class. This solves a recurring problem: code that directly calls new ConcreteType() becomes tightly coupled to that type, making it hard to introduce variants or swap implementations without editing every call site.

How It Works

The pattern has four roles. The Product is an abstract type (interface or base class) that defines what created objects can do. Concrete Products implement it. The Creator declares the factory method, which returns a Product; it may also contain core business logic that uses the product. Concrete Creators override the factory method to return a specific Concrete Product.

The key is inversion: the Creator's other methods depend only on the Product abstraction, so they remain stable while subclasses vary what gets built. A common refinement is a parameterized factory method that selects a product based on an argument, collapsing many subclasses into one switch.

When to Use It

Reach for Factory Method when a class cannot anticipate the exact type of object it must create, when you want subclasses to specify the objects, or when you want to centralize and name the construction logic. It is also useful when object creation is non-trivial — requiring configuration, caching, or validation — and you want that logic in one place rather than scattered across the codebase.

It is overkill for simple value objects that never vary. If you only ever create one concrete type, a plain constructor is clearer.

Trade-offs

The main benefit is loose coupling between client code and concrete classes, which supports the open/closed principle: new products require new subclasses, not edits to existing logic. It also gives a single, testable seam where construction can be mocked or substituted.

The cost is added indirection. Each new product can demand a new Creator subclass, increasing the class count and making the hierarchy harder to follow. Developers new to the codebase may struggle to trace which concrete type a factory method returns at runtime. Parameterized factories mitigate the class explosion but reintroduce a conditional that must be maintained.

Related Patterns

Factory Method is often confused with Abstract Factory: Factory Method uses inheritance and creates one product per method, while Abstract Factory uses composition and creates families of related products. Template Method frequently calls a factory method as one of its steps. Prototype offers an alternative — cloning an existing instance instead of subclassing a creator.

Example

A cross-platform UI toolkit declares a Dialog creator with a createButton() factory method returning a Button. WindowsDialog overrides it to return a WindowsButton; WebDialog returns an HtmlButton. The Dialog.render() method calls createButton() and lays the button out without knowing the concrete class. Adding a macOS variant means adding one subclass — no existing code changes.