Creational · 1 of 5
Factory Method
Factory Method is a creational pattern that puts “which class should we construct?” in one place. Callers ask for a interface; they never write new Car().
Without it you get new CompactSpot() in the entry gate, the same call in the admin tool, and a switch on VehicleType in both. A van arrives — you edit two switches and miss the third. One factory owns the constructors instead.
Who is allowed to know the concrete class?
One product
Factory Method answers “which Vehicle?” If you only have one kind of thing to create, stop here. Do not invent a kit.
Not a family
Abstract Factory answers “which matching family?” Button plus Dialog plus Menu. A family of one is still Factory Method.
Not assembly
Builder picks how a particular object is assembled. Factory Method picks which class is born.
Collaboration
The caller never names Car
EntryController holds a . A new van lands in the factory, not in the controller.
Read the diagram definition
flowchart LR
Caller[EntryController] --> F[VehicleFactory.from]
F -->|car| Car
F -->|bike| Bike
F -->|van| Van
Car --> V[Vehicle]
Bike --> V
Van --> V
Caller --> Lot[ParkingLot.park]Classic shape — subclass decides the product
The Gang of Four picture: an abstract creator declares createVehicle. Subclasses override it. The rest of the algorithm — admit, park, issue a ticket — stays in the base type.
interface Vehicle {
String plate();
}
abstract class Gate {
Ticket admit(String plate) {
Vehicle v = createVehicle(plate); // factory method
return lot.park(v);
}
protected abstract Vehicle createVehicle(String plate);
}
class CarGate extends Gate {
protected Vehicle createVehicle(String plate) { return new Car(plate); }
}This is the inheritance form. It shines when the creator already has a useful skeleton (admit, then park) and only the product varies. It is awkward when you would invent a Gate subclass per vehicle type just to hide new.
Practical shape — a registry the caller never sees
In a short interview, prefer an injected factory that owns a . That is still Factory Method in spirit: one place knows constructors. It is also a if you skip the creator hierarchy — and that is fine. Say that plainly.
interface VehicleFactory {
Vehicle from(String numberPlate, String rawType);
}
class RegistryVehicleFactory implements VehicleFactory {
private final Map<String, Function<String, Vehicle>> byType = Map.of(
"car", Car::new,
"bike", Bike::new,
"van", Van::new
);
public Vehicle from(String numberPlate, String rawType) {
var ctor = byType.get(rawType.toLowerCase());
if (ctor == null) throw new IllegalArgumentException(rawType);
return ctor.apply(numberPlate);
}
}
class EntryController {
private final VehicleFactory vehicles;
EntryController(VehicleFactory vehicles) { this.vehicles = vehicles; }
Ticket enter(String plate, String type) {
return lot.park(vehicles.from(plate, type));
}
}Factory Method is not Creator (GRASP)
Ownership new is fine
still applies. ParkingLot may create Ticket because it records tickets. That is not a factory. That is “I own this collection, so I mint the next id.”
Varying type needs a factory
Reach for Factory Method when the type itself varies: vehicles, spots, handlers, channels. Prefer returning an interface. Prefer a map over a growing switch. Prefer injecting the factory so tests can return a fake.
Decision
Which creational name?
- 1
One product type, vary the class?
Factory Method (this page).
- 2
Several products that must match a theme or vendor?
Abstract Factory.
- 3
One object, many optional parts and validation?
Builder.
- 4
A correct example already sits in memory?
Prototype.
- 5
Truly one process-wide resource — and tests can still replace it?
Usually inject. Rarely Singleton.
A factory that still leaks new
If EntryController and AdminPanel both still switch on type, you renamed the problem. One factory, every caller asks it. A new van is one map entry, not three edits.
Abstract Factory because the name sounds bigger
One product — Vehicle — is Factory Method. A matching set — DarkButton + DarkDialog, or PdfHeader + PdfBody + PdfFooter — is Abstract Factory. Do not invent a family of one product.
How this shows up in a parking-lot round
The interviewer adds a van, then an EV, then a truck that only fits large spots. If park() still switches on type to construct the vehicle, you will miss a branch. Extract VehicleFactory, inject it, and keep allocation as Strategy. Creation and choice are different seams.
Tests pass a factory that always returns a Bike. That is dependency injection, not a framework. A constructor argument is enough.
How to explain this in an interview
- Early. “Vehicle types will grow. I will hide constructors behind a VehicleFactory so EntryController never writes Car.”
- Next. Sketch the interface and a map. Do not create a Gate subclass per type unless the admit skeleton is already useful.
- Follow-up (van). One map entry. If you also edit pricing, that is a second seam — Strategy or a registry — not a second factory method on Vehicle.
A static Vehicles.from(type) is a Simple Factory. Say the name. Interviewers care that constructors have one owner, not that you inherited Gate.