Gof Factory Method

Factory Method

Purpose

Let an inherited algorithm create an object whose concrete type it must not know. The creator class supplies workflow behaviour and delegates product creation to an overridable method. Other hooks and creation arguments can coexist with this pattern.

That is a narrow pattern, and most code labelled Factory Method is not it. A static of(...) on the type itself is a static factory method: a named constructor with the freedom to cache, return a subtype and be given a meaningful name. It solves a different problem — naming and control over instantiation — and it involves no subclass and no hook. Both are useful; calling them the same thing is how a Supplier turns into a class hierarchy.

When it is the answer

Inspect the project's compiler release, toolchain, framework construction path and callers before changing a public extension point. Examples are partial Java 17 sketches with domain types/imports omitted; pattern matching over a sealed kind requires Java 21 without preview. Keep the target baseline; do not upgrade it to adopt an alternative.

An algorithm is inherited, and its only variation point is which
concrete product it creates
        → Factory Method (this is Template Method whose varying step
          is construction).

A framework must let unknown subclasses supply the product, and
cannot accept constructor arguments (it instantiates the subclass
itself)
        → Factory Method. This is why frameworks use it and
          applications usually should not.

The product type must correlate with the creator's own type — a
DocumentReader subtype pairs with its Document subtype
        → Factory Method, with the covariant return declared.

When it is not

• The creator has no inherited algorithm. Consider a Supplier, but keep a named domain provider when checked failures, arguments, lifecycle or a published SPI justify its contract.
• Subclassing exists only to change the created type. Pass the creation function in. One object with a field beats two types in a hierarchy (java-composition-over-inheritance).
• The selection is data-driven. Map<Kind, Supplier<T>> or a sealed Kind with an exhaustive switch is clearer than a subclass per kind, and the set of kinds is visible in one place.
• Tests are the reason. Subclassing production code to override createX() couples the test to the hierarchy and to protected members; an injected Supplier is a seam that costs nothing to read (java-test-doubles).
• You mean a named constructor. Write static Money of(...). Do not build a hierarchy to get a name.

Modern Java expression

Classical                            Modern equivalent
───────────────────────────────────  ────────────────────────────────────
abstract class Creator {             final class Creator {
  abstract Product create();           private final Supplier<Product> create;
  void run() { ... create() ... }      void run() { ... create.get() ... }
}                                    }

class PdfCreator extends Creator     Creator pdf = new Creator(PdfProduct::new);

subclass-per-kind selection          Map<Kind, Supplier<Product>>
                                     or sealed Kind + exhaustive switch

open extension by third parties      ServiceLoader<ProductProvider>

The method reference PdfProduct::new is a creation function, not the GoF Factory Method pattern: it preserves deferred creation while replacing inheritance with composition. Keep the abstract hook when the framework's actual extension contract requires it and offers no suitable injection seam, or when the product type is covariant and callers rely on that contract.

Decision rules

IF the base class has no behaviour other than the abstract create()
THEN consider a Supplier; preserve meaningful domain and public extension contracts.

IF a constructor calls the overridable factory method
THEN subclass state may still hold default values. Prefer injected creation;
     any deferred init must occur after construction and enforce readiness.

IF subclasses exist only to select products and the extension set is application-controlled
THEN composition through suppliers, a keyed map, or a sealed kind is usually simpler.
     Keep the hook when open framework extension or creator/product covariance is material.

IF the product must vary per call, from an argument
THEN compare an argument-taking hook with Function<Input, Product>;
     arguments do not disqualify Factory Method.

IF several related products must vary together
THEN Abstract Factory, not N independent factory methods
     (gof-abstract-factory).

IF the creator caches or reuses what it creates
THEN a lifetime has been introduced. Say what it is; do not let a
     factory method quietly become a singleton or a pool.

IF the method is static and lives on the product type
THEN it is a static factory method. Judge it by naming and instance
     control (java-object-construction), not by this pattern's criteria.

Cross-cutting checks

• Concurrency. The classic defect is a constructor invoking the overridable factory method: subclass state can be read before initialization; cross-thread exposure additionally requires the creator to escape. Avoid overridable constructor calls (java-composition-over-inheritance). Lazy caching needs safe publication and an initialization policy: a volatile field alone does not prevent duplicate creation. Specify failure/retry and disposal of losing instances.
• Distribution. Nothing crosses a boundary here, with one exception: when the product kind is chosen from externally supplied data (a message type header, a content type), that key must be validated against a closed set before it selects a class. Reflective instantiation from an unvalidated name is a deserialisation vulnerability, not a factory.
• Performance. The hook implies neither one allocation nor failed inlining: implementations may cache products, and HotSpot can inline stable virtual calls. A highly polymorphic hot call site can inhibit inlining, but only profiles and compilation evidence establish that (jit-inlining-and-escape-analysis).
• Testing. An injected Supplier avoids coupling new tests to protected hooks. A test subclass can still be a useful characterization seam for an existing public extension point; do not remove that contract solely to simplify tests.

Review checklist

For a review, return the concrete hook/call sites, creation frequency and ownership, chosen alternative or reason to retain the hook, and checks performed versus pending. If framework construction or external subclass usage is unknown, keep removal conditional until inspected.

• The creator has real inherited behaviour, not just the hook
• No constructor calls the overridable factory method
• The hook is not present solely to give tests a substitution point
• Subclassing is justified by an inherited algorithm, open extension constraint, or useful creator/product type relationship—not merely by a closed application selection table
• Any externally supplied product key is validated against the supported registry; reflective class loading is not driven directly by untrusted input
• Lazy caching inside the hook, if present, is correctly published
• Covariant return types are declared where callers depend on the product subtype
• A static of/from/valueOf is described as a static factory, not as this pattern

References

• Decision and alternatives — the three meanings of "factory method" separated, the hook against Supplier, keyed maps, ServiceLoader and dependency injection, the constructor trap in full, and how the pattern relates to Template Method and Abstract Factory. Read before adding or removing a creation hook.
• Worked example — an import pipeline whose subclasses existed only to pick a parser, converted to an injected supplier and then to a keyed map, alongside a framework case where the hook correctly stays. Read when refactoring a creator hierarchy.