# Gof Factory Method > Factory Method in modern Java, and the three different things that share its name: the GoF pattern (a creation hook a subclass overrides inside an inherited algorithm), Effective Java's static factory method (a named constructor, not this pattern), and any method someone called createX. Covers when the subclass hook is genuinely right, why an injected Supplier or a keyed map replaces it in most application code, and the constructor-calls-an-overridable-method trap it invites. Use when a protected createX() hook is proposed, when a class is subclassed only to change which type it instantiates, when tests subclass production code to substitute an object, when a static factory is being called Factory Method in review, or when deciding between a subclass hook and a Supplier. Does not cover families of related products (gof-abstract-factory), the surrounding algorithm skeleton (gof-template-method), or static factory naming conventions (java-object-construction). - Skill: `robsonkades/gof-factory-method` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add robsonkades/gof-factory-method` - Raw SKILL.md: https://api.skillmd.com/api/skills/robsonkades/gof-factory-method/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: robsonkades (https://skillmd.com/u/robsonkades) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/robsonkades/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. ```text 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>` 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 ```text Classical Modern equivalent ─────────────────────────────────── ──────────────────────────────────── abstract class Creator { final class Creator { abstract Product create(); private final Supplier create; void run() { ... create() ... } void run() { ... create.get() ... } } } class PdfCreator extends Creator Creator pdf = new Creator(PdfProduct::new); subclass-per-kind selection Map> or sealed Kind + exhaustive switch open extension by third parties ServiceLoader ``` 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 ```text 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; 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](references/decision-and-alternatives.md) — 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](references/worked-example.md) — 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.