The Factory Pattern

A factory centralises the decision about which concrete type to create. The caller asks for something by name or by criteria, and the factory returns the object. The caller ends up holding the interface, so it never names the concrete class, and the knowledge of the available implementations lives in exactly one place.

public class Main {
    public static void main(String[] args) {
        Notification n = NotificationFactory.create("email");
        System.out.println(n.send("hello"));
        Notification m = NotificationFactory.create("sms");
        System.out.println(m.send("hello"));
    }
}

interface Notification {
    String send(String message);
}

class EmailNotification implements Notification {
    public String send(String message) { return "email sent: " + message; }
}

class SmsNotification implements Notification {
    public String send(String message) { return "sms sent: " + message; }
}

class NotificationFactory {
    static Notification create(String channel) {
        if ("email".equals(channel)) { return new EmailNotification(); }
        if ("sms".equals(channel)) { return new SmsNotification(); }
        throw new IllegalArgumentException("unknown channel: " + channel);
    }
}

The output shows the separation working. The main method asks for an email notification and gets one, then asks for a text message and gets the other, and it never mentions either implementation class. The only place that knows both exist is the factory.

That matters most when creation is not trivial. If building a notification involved reading configuration, choosing a transport, retrying a connection or applying a template, that code would otherwise be scattered across every caller, and each copy would drift. Centralising it means the rules live in one file.

The other benefit is that the factory can return different types based on data. A method that takes a configuration and picks the implementation removes a chain of conditions from the caller. The trade-off is real, though: an extra layer to read, and a factory whose body is a long chain of conditionals has simply moved the problem rather than solved it.

The rule to state in an interview is that the factory earns its place when creation involves a decision. If the constructor call is obvious and nothing varies, use the constructor directly.

Use a factory when there is a decision to make about the type, when creation involves work you do not want repeated in every caller, or when you want the caller to depend on an interface rather than on a concrete class. A factory that takes a type name and returns the right implementation is also useful when the set of implementations is chosen at run time from configuration.

Two alternatives are worth knowing. A static factory method on the class itself, with a name that says what it produces, keeps the creation next to the class and reads better than a constructor for cases with the same name but different arguments. And an abstract class with a static factory method per implementation gives each implementation its own entry point, which is a common shape in the standard library.

There is also the plain constructor, which is right more often than people expect. If creating the object is a single obvious call, a constructor is clearer than a factory, and the caller is free to depend on the concrete type, which is not a problem when there is only one.

The warning to give is against a factory that has become a chain of conditionals mapping strings to constructors. That has moved the branching rather than removed it, and the smell to look for is a factory whose body is longer than the constructors it calls.