Factory Method Pattern

1The problem it solves#

This situation shows up constantly. Name it fast and the pattern sells itself.

• You are writing logic that creates an object, does work with it, and returns a result.
• The work is the same every time.
• The type of object you create changes with context.

A logistics app makes it concrete. The flow is identical: take an order, plan a delivery, dispatch it. Some orders ship by truck, some by drone. The naive version:

public String planDelivery(String mode) {
    Transport t;
    if (mode.equals("truck")) {
        t = new Truck();
    } else if (mode.equals("drone")) {
        t = new Drone();
    } else {
        throw new IllegalArgumentException("unknown mode");
    }
    return t.deliver();
}

This works until it does not. Each symptom is a separate reason the design rots:

• Every new shipping mode means cracking open this method and bolting on another else if.
• Six modes later it is a 40-line conditional that every engineer is scared to touch.
• The method knows about every concrete class in the system. new Truck() is welded into the business logic.
• You cannot unit test the planning logic without dragging real transport classes along: a test that should run in 2ms now spins up a truck object.
• You keep editing a method that, conceptually, you finished months ago.

2The idea (mental model)#

Here is how I hold it in my head.

• Declare a creation method, leave it empty in the base class, and let each subclass decide what to build.
• The base class writes the recipe. It calls its own createTransport() in the middle of its logic.
• It does not know, and does not care, what that method returns.
• TruckLogistics overrides createTransport() to return a Truck. DroneLogistics returns a Drone.
• The recipe never changes. Only the one creation step swaps per subclass.

The trick that makes it click:

• The base class calls a method it declares but does not implement.
• The subclass supplies the "what." The base class owns the "when" and "how it gets used."
• That inversion is the whole pattern, and it is a textbook Dependency Inversion case: high-level policy (the delivery recipe) depends on an abstraction (Transport), and the low-level detail (which concrete transport) is pushed down into the subclass.

Keep the three cousins separate and you will never trip in an interview:

• Simple Factory: a static method with a switch inside. Not really a pattern, more a coding habit.
• Abstract Factory: creates families of related objects.
• Factory Method: one product, one virtual creation method, decided by subclass.

The factory is not the main character. The Creator is.

3Structure#

Four roles. Learn them as a cast, not a diagram.

• Product interface: the type your business logic talks to (Transport).
• ConcreteProduct: the real things (Truck, Drone).
• Creator: the abstract class that holds your logic and declares the factory method (Logistics).
• ConcreteCreator: subclasses that override the factory method to return a specific product.

Why the Creator is the star:

• People think the "factory" is the main character.
• The Creator usually has a real method with real logic that uses the product.
• The factory method is a small, overridable piece inside a larger stable flow.

4Implementation in Java#

// Product
interface Transport {
    String deliver();
}

// Concrete products
class Truck implements Transport {
    public String deliver() {
        return "Delivering by road in a box.";
    }
}

class Drone implements Transport {
    public String deliver() {
        return "Delivering by air to the doorstep.";
    }
}

// Creator: holds the real logic, declares the factory method
abstract class Logistics {

    // the factory method, subclasses decide what to build
    protected abstract Transport createTransport();

    // the stable business logic, written once, never touched again
    public String planDelivery() {
        Transport t = createTransport();
        String route = "Route planned. ";
        return route + t.deliver();
    }
}

// Concrete creators
class TruckLogistics extends Logistics {
    protected Transport createTransport() {
        return new Truck();
    }
}

class DroneLogistics extends Logistics {
    protected Transport createTransport() {
        return new Drone();
    }
}

Using it:

public class Demo {
    public static void main(String[] args) {
        Logistics logistics = pickLogistics("drone");
        System.out.println(logistics.planDelivery());
    }

    static Logistics pickLogistics(String region) {
        // one place decides which creator, usually config or input
        if (region.equals("drone")) return new DroneLogistics();
        return new TruckLogistics();
    }
}

Notice what happened to the if. It did not vanish. It moved.

• It left planDelivery where it corrupts your core logic.
• It now lives in one small spot at the edge that only chooses which creator to instantiate.
• planDelivery is closed to modification.
• Add a ShipLogistics tomorrow and you touch exactly two spots: a new three-line subclass, and the one branch in pickLogistics.
• planDelivery never gets opened again. That is the Open/Closed Principle actually doing something, not just a slogan.

5A real-world example#

You have used this pattern a hundred times without naming it.

• Collection.iterator() is a factory method: ArrayList returns an array-backed iterator, LinkedList returns a node-walking one, and your for-each loop never knows the difference.
• Calendar.getInstance() hands back a locale-appropriate concrete calendar.
• Both are "I call a method to get an object and I do not control which concrete class comes back."

In a real LLD loop it shows up as a document editor.

• The Application class has an openDocument() flow: check permissions, load bytes, render.
• A DrawingApp creates DrawingDocument objects, a TextApp creates TextDocument objects.
• Rather than branching inside openDocument, each app subclass overrides createDocument().
• The open flow is written once in the base Application.
• This is the exact example from the Gang of Four book, so naming it signals you know the source, not just a blog summary.

Another one I like: a notification system.

• Base NotificationService has send(message) that logs, rate-limits, and dispatches.
• Subclasses override createChannel() to return an EmailChannel, SmsChannel, or PushChannel.
• The rate-limiting and logging code gets written exactly once and inherited by all three.

Here is the runtime flow for the logistics example, since the order of calls is what people miss:

6When to use it, and when not to#

Reach for Factory Method when:

• You have a stable algorithm that creates and uses an object, and the type of that object varies by subclass or context.
• You want users of a framework to plug in their own product types without you rewriting the core flow. This is why frameworks love it: Spring, JUnit, and the servlet spec all lean on it.
• The creation logic is genuinely subject to change and you want it isolated behind one overridable method.

Leave it on the shelf when:

• You only ever create one type of object. Then new Thing() is correct and a factory is theater.
• The decision is a simple one-time switch with no shared surrounding logic. A plain static factory method, or a Map of suppliers, is lighter and honest about what it is.
• You would be creating an abstract class and two subclasses purely to avoid a two-branch if. That is more classes, not better design.

7Common mistakes#

The ones that actually come up, in the order they cost you.

• Calling Simple Factory "Factory Method." A static method with a switch is not this pattern. Factory Method uses subclassing and overriding. Miss this and I catch it in the first two minutes.
• Putting no logic in the Creator. If planDelivery just returns createTransport().deliver() with nothing around it, you added three classes for nothing. The Creator earns its keep through the stable logic that surrounds the creation call.
• Making the factory method public and treating it as the API. The product of the pattern is usually the business method (planDelivery), not createTransport. Keep the factory method protected. Clients talk to the real behavior, not the creation hook.
• Confusing it with Abstract Factory. Factory Method: one product, decided by subclass, via method override. Abstract Factory: a family of products, usually composed in as an object you hold. Different shapes, different problems.
• Subclass explosion. Ten creator subclasses that each differ by one line means the variation belongs in data, not in types. Reach for a registry of suppliers, a Map<String, Supplier<Transport>>, instead.

8Where it shows up in interviews#

LLD interviewers plant this everywhere.

• Design a logging framework, a payment processor, a ride-matching service, a maze game with different room types.
• The trigger phrase: "the system should support adding new types of X later without changing existing code."
• That is your cue to name Factory Method and show the Creator holding the stable flow.

Two moves score points.

• Say out loud why you are not just using new: "I want the creation decision isolated so the open flow stays closed to modification." Interviewers want the reasoning, not the recital.
• Draw the four roles fast and point at the dependency arrow from Creator to the Product interface. That one arrow proves you understand the decoupling, which is the entire point.

And if the problem genuinely needs one object type, say so and use a constructor. Knowing when not to apply a pattern is the staff-bar signal.

Next, look at Abstract Factory for creating product families, and the Strategy pattern, which also injects behavior but through composition rather than subclass overriding.