skip to content

What are the conventional names for static factory methods, and what does each communicate to a caller?

level: juniorimportance: should knowfreq 45%

answer

  1. from = 1-arg conversion; of = aggregate many
  2. valueOf = value conversion (Integer.valueOf)
  3. getInstance = maybe shared; newInstance = always new
  4. getType/newType = factory in a different class
  5. Name signals new-vs-cached identity

basics

~20 s

Common factory names are of (combine several args), valueOf (convert a value), getInstance (give an instance, maybe shared), newInstance (give a brand-new one), and from (convert one arg). Following them makes the method's intent obvious.

solid answer

~40 s

Because static factories aren't forced to match the class name, the community uses a shared naming vocabulary so a method's behavior is recognizable. of takes several parameters and aggregates them: List.of(a, b, c). valueOf is a type-conversion alternative to a constructor: Integer.valueOf("42"). from does a single-argument conversion: Date.from(instant). getInstance (or instance) returns an instance described by its parameters and may return a shared one, e.g. a singleton: Calendar.getInstance(). newInstance (or create) is like getInstance but guarantees a distinct new object each call. When the factory lives in a different class than the object it returns, you append the type name: getType / newType, as in Files.newBufferedReader. Using these names signals intent — especially whether you get a fresh object or a possibly-cached one — and improves discoverability of an otherwise easy-to-miss method.

go deeper

for a junior

Recognizes the common names (of, valueOf, getInstance, from) and can pick a reasonable one when writing a simple factory.

for a middle

Maps each name to its precise meaning, especially getInstance (possibly shared) vs newInstance (always new), and the getType/newType cross-class variants.

for a senior

Chooses names deliberately to communicate object-identity guarantees and reviews teammates' factories for misleading names.

for a principal

Sets and enforces naming conventions across a codebase/library so factory semantics (shared vs new, conversion vs aggregation) are predictable to all consumers.

## Why naming matters here A constructor is always named after its class, so its meaning is fixed. A **static factory** can be named anything, which is powerful but risks confusing callers. The Java community therefore evolved a **conventional vocabulary** (codified in *Effective Java* Item 1). Following it lets a reader infer behavior — most importantly **whether a call allocates a new object or may return a shared one** — without reading the source. ## The conventions - **`from`** — a **type-conversion** method that takes a **single** argument and returns an instance: `Date.from(instant)`, `Instant.from(temporalAccessor)`. - **`of`** — an **aggregation** method that takes **multiple** parameters and combines them: `List.of(a, b, c)`, `Set.of(...)`, `EnumSet.of(RED, GREEN)`. - **`valueOf`** — a more verbose alternative to `from`/`of`, typically a **value conversion**: `Integer.valueOf("42")`, `BigInteger.valueOf(7)`. - **`instance`** or **`getInstance`** — returns an instance *described by* its parameters (if any), but **cannot be said to return the same object** — it *may* return a shared/cached one (singletons): `Calendar.getInstance()`, `Runtime.getRuntime()`. - **`create`** or **`newInstance`** — like `getInstance`/`instance`, but **guarantees each call returns a new, distinct instance**: `Array.newInstance(type, len)`. - **`getType`** — like `getInstance`, but used when the factory is in a **different class** than the returned object; `Type` is the returned object's type: `Files.getFileStore(path)` returns a `FileStore`. - **`newType`** — like `newInstance`, but the factory is in a **different class**; returns a new object of `Type`: `Files.newBufferedReader(path)`. ## The key distinction to internalize The most useful signal in this vocabulary is **`getInstance` (maybe shared) vs `newInstance` (always new)**. If you write a factory, choose the name that tells the truth about object identity — a caller relying on `==` or on independent mutable state needs to know whether they got a fresh object. ## Discoverability Naming conventions also partly mitigate the *discoverability* weakness of factories: a developer scanning a class's methods recognizes `of`/`valueOf`/`getInstance` as the way to obtain instances. Pair the convention with clear class-level Javadoc that points to the factories, since they don't get a dedicated 'Constructor Summary' section. ## Anti-pattern Don't invent idiosyncratic names (`makeOne`, `build` for a non-builder, `construct`) when a standard one fits — and don't name something `newX` if it may return a cached instance, or `getX`/`valueOf` if callers might depend on identity in a way the name contradicts.

  • A teammate names a caching factory createUser(). Why is that name misleading?
    By convention create / newInstance promise a brand-new, distinct instance per call. If the method actually returns a cached or shared object, the name lies about identity; callers may wrongly assume independent state or fresh allocation. getInstance (or of/valueOf) would correctly signal a possibly-shared result.

saying these in an interview costs you the question

  • Using newInstance/create for a method that returns a cached or shared instance.
  • Treating of and valueOf as identical — of aggregates multiple params, valueOf is a value conversion.
  • Inventing nonstandard names (makeFoo, constructFoo) when a conventional one fits, hurting recognizability.
  • Confusing the getType/newType convention (factory in a different class) with getInstance/newInstance (same class).

context

resolving links…