Factory Pattern vs Builder Pattern
Factory vs Builder pattern in Java — when to use each, telescoping constructors, and a side-by-side code example for interviews.
Expected Interview Answer
The Factory pattern encapsulates object creation behind a single method call that returns a fully-formed object of a chosen type, while the Builder pattern constructs a complex object step by step through a fluent sequence of calls, assembling it piece by piece before a final build() step.
A Factory is the right tool when creation logic simply needs to decide WHICH concrete class to instantiate based on input, and the object can be created in one shot with a small, fixed set of arguments. A Builder is the right tool when an object has many optional fields, an order-sensitive assembly process, or a constructor that would otherwise need many overloaded parameters ("telescoping constructor" problem). Builders also let intermediate state be validated incrementally and allow immutable objects to be assembled without exposing setters. Both patterns hide the “new” call from client code, but Factory answers “what type do I create” whereas Builder answers “how do I assemble something complex step by step.”
- Factory centralizes type-selection logic in one place
- Builder eliminates telescoping constructors with many optional fields
- Builder supports fluent, readable object assembly
- Both decouple client code from concrete construction details
AI Mentor Explanation
A factory is the groundstaff office that hands you a ready-made pitch type — "green pitch" or “dry spin pitch” — you name the type and get the finished result in one request. A builder is preparing a custom kit bag piece by piece: choose the bat, then the pads, then the gloves, then the helmet, confirming the full assembly only at the end. The factory picks among fixed finished products; the builder assembles a complex, customizable one step at a time.
Step-by-Step Explanation
Step 1
Recognize the creation need
Decide whether you need to pick among fixed finished types (Factory) or assemble a complex customizable object (Builder).
Step 2
Factory: encapsulate type selection
A single createX(type) method returns the correct concrete implementation based on input.
Step 3
Builder: chain assembly steps
Expose fluent setter-like methods that return the builder itself, accumulating configuration.
Step 4
Finalize construction
Factory returns the object directly; Builder exposes a build() call that validates and produces the final immutable object.
What Interviewer Expects
- Clear articulation of “what type” (Factory) versus “how to assemble” (Builder)
- Recognition that Builder solves the telescoping-constructor problem
- A concrete Java example distinguishing the two
- Awareness that both hide “new” from client code but solve different problems
Common Mistakes
- Treating Factory and Builder as interchangeable
- Using a Builder when a simple Factory would suffice for a fixed, small object
- Forgetting that Builder typically produces immutable objects via a final build() call
- Not mentioning the telescoping-constructor motivation for Builder
Best Answer (HR Friendly)
“A Factory is like ordering a ready-made item by name — you ask for a type and get a complete object back in one step. A Builder is for objects with lots of optional pieces, where you configure them step by step and only get the final result once you are done assembling. I would reach for a Factory when choosing among a few fixed types, and a Builder when an object has many optional or order-sensitive parts.”
Code Example
interface Shape { void draw(); }
class Circle implements Shape { public void draw() { System.out.println("Circle"); } }
class Square implements Shape { public void draw() { System.out.println("Square"); } }
class ShapeFactory {
static Shape create(String type) {
if (type.equals("circle")) return new Circle();
if (type.equals("square")) return new Square();
throw new IllegalArgumentException("Unknown type");
}
}
class Pizza {
private final String size;
private final boolean cheese;
private final boolean pepperoni;
private Pizza(Builder b) {
this.size = b.size;
this.cheese = b.cheese;
this.pepperoni = b.pepperoni;
}
static class Builder {
private String size = "medium";
private boolean cheese = false;
private boolean pepperoni = false;
Builder size(String s) { this.size = s; return this; }
Builder cheese(boolean c) { this.cheese = c; return this; }
Builder pepperoni(boolean p) { this.pepperoni = p; return this; }
Pizza build() { return new Pizza(this); }
}
}
Shape s = ShapeFactory.create("circle");
Pizza p = new Pizza.Builder().size("large").cheese(true).pepperoni(true).build();Follow-up Questions
- When would you choose a Builder over a Factory for the same object?
- How does the Abstract Factory pattern extend the Factory pattern?
- Why does the Builder pattern often produce immutable objects?
- Can a Factory method internally use a Builder?
MCQ Practice
1. The Factory pattern primarily solves which problem?
Factory centralizes and hides the logic for choosing which concrete class to instantiate.
2. The Builder pattern is most useful when?
Builder avoids telescoping constructors and supports complex, step-by-step object assembly.
3. In the Pizza builder example, what does calling build() do?
build() finalizes accumulated configuration into a completed, typically immutable object.
Flash Cards
Factory pattern in one line? — One call returns a fully-formed object of a chosen concrete type.
Builder pattern in one line? — Assembles a complex object step by step via chained calls, finalized with build().
What problem does Builder solve? — The telescoping-constructor problem for objects with many optional fields.
Key question to distinguish them? — Factory: what type? Builder: how to assemble?