What is the Factory Method pattern, and how does it differ from calling a constructor directly?

## The problem it solves When you write `new ArrayList<>()`, your code is *hard-wired* to the exact class `ArrayList`. The word **coupling** means a dependency between two pieces of code: here the caller is coupled to a concrete class. Coupling to concrete classes is brittle — if you later want a different implementation, you must edit every place that said `new ArrayList<>()`. The **Factory Method pattern** removes that coupling by moving the `new` behind a method. Instead of constructing the object yourself, you call a method that constructs it for you and hands it back. Because the method's declared **return type** is an *abstraction* (an `interface` or a parent `class` — a type that says *what* the object does, not *which* concrete class it is), the caller never learns the concrete class. That concrete class can change freely. ## Constructor vs factory method A **constructor** is the special block invoked by `new ClassName(...)`. It has hard rules: its name must equal the class name, and `new` always returns a brand-new instance of *that exact class*. A **factory method** is just a normal method that returns an object. Compared to a constructor it gains three powers: 1. **A meaningful name.** `BigInteger.probablePrime(...)` reads better than a bare constructor and lets two factories with the same parameter types coexist (constructors can't — they'd have identical signatures). 2. **It can return a subtype.** The declared return type might be `List`, but the actual object could be an `ArrayList`, an immutable list, or an empty-list singleton. The caller doesn't know or care. 3. **It need not create a new object.** It may return a cached or shared instance (e.g. `Boolean.valueOf(true)` always returns the same `Boolean`). A constructor *must* allocate. ## The GoF "Factory Method" vs the everyday Java usage There are two senses of the term and interviews probe both: - **GoF Factory Method (the design pattern):** a *creator* class declares an abstract or overridable method like `createProduct()` that returns a *product* type; concrete subclasses of the creator override it to decide which concrete product to build. The creator's other methods call `createProduct()` without knowing the concrete product. This is *deferred instantiation*: the superclass defines the algorithm, the subclass chooses the object. The variation point is **inheritance** — you subclass the creator. - **Static factory method (Effective Java sense):** a `static` method on a class that returns an instance of that class (or a related type), e.g. `Integer.valueOf(int)`, `List.of(...)`, `Calendar.getInstance()`. There is no creator hierarchy; the method is simply a named, smarter alternative to a public constructor. Most Java code that people loosely call "factory method" is this static-factory form. Both share the core idea: **the caller asks for an object by intent, not by class name**, and the production code decides the concrete type. ## A minimal example ```java interface Notifier { void send(String msg); } class EmailNotifier implements Notifier { public void send(String msg) { /* ... */ } } class NotifierFactory { // factory method: returns the abstraction, hides the concrete class static Notifier create(String channel) { return switch (channel) { case "email" -> new EmailNotifier(); default -> throw new IllegalArgumentException(channel); }; } } // caller is coupled only to Notifier, never to EmailNotifier: Notifier n = NotifierFactory.create("email"); ``` The caller depends on `Notifier` only. Swapping in an `SmsNotifier` is a one-line change inside the factory; no caller changes. ## Why it matters It is the concrete realization of the **Dependency Inversion Principle** (depend on abstractions, not concretions) at the point of object creation, and it underpins much of the JDK and frameworks like Spring, where you rarely call `new` on the things you consume.