Creational Patterns • Builder PatternHard⏱️ ~3 min
Builder Pattern: When to Use and Trade-Offs
When Builder is Appropriate:
Use Builder When:
First, Object has four or more parameters with at least two being optional. This is a rule of thumb, but context matters. A
Second, Construction involves validation that depends on parameter combinations. Example: a
Third, Immutability is desired after construction. Builder allows accumulating state during construction, then freezing it into an immutable product. This is common in domain models and DTOs (Data Transfer Objects).
Fourth, The same construction process should produce different representations. A
First, Object has four or more parameters with at least two being optional. This is a rule of thumb, but context matters. A
Rectangle(x, y, width, height) with four required parameters does not need a builder because there is no optionality or construction complexity.Second, Construction involves validation that depends on parameter combinations. Example: a
Report might require either a dateRange OR a fiscalQuarter, but not both. The build() method validates this mutual exclusivity.Third, Immutability is desired after construction. Builder allows accumulating state during construction, then freezing it into an immutable product. This is common in domain models and DTOs (Data Transfer Objects).
Fourth, The same construction process should produce different representations. A
MealBuilder could produce VegetarianMeal, VeganMeal, or RegularMeal depending on how it is configured, but this is rare in LLD interviews compared to simpler single-product builders.Overkill Scenario
Point class with only x and y coordinates. Two required parameters with no validation.Solution: Simple constructor
Point(x, y)→
Appropriate Scenario
SearchQuery with keyword, filters (category, price range, rating), sort order, pagination (page, size).Solution: Builder with required keyword, optional filters
Builder vs Alternatives:
Builder vs Telescoping Constructors:
Telescoping creates multiple constructors:
Builder vs JavaBeans (Setters):
JavaBeans uses a no-arg constructor and setters. This allows inconsistent state: an object might be used before all required fields are set. Builder enforces required fields in its constructor and produces an immutable object. Trade-off: JavaBeans is simpler for frameworks that require no-arg constructors (like some ORMs or serialization libraries), but Builder is superior for domain logic where consistency matters.
Builder vs Factory:
Factory encapsulates object creation logic, often choosing which subclass to instantiate based on parameters. Builder focuses on step-by-step construction of a single complex object. They can be combined: a factory might return a pre-configured builder. Trade-off: Use Factory when the decision is WHICH type to create. Use Builder when the decision is HOW to configure a known type.
Builder vs Method Chaining on Product:
Why not have
Builder vs Telescoping Constructors:
Telescoping creates multiple constructors:
Foo(a), Foo(a, b), Foo(a, b, c). This explodes with optional parameters (2^n combinations). Builder handles this with one constructor for required parameters and fluent methods for optional ones. Trade-off: Builder adds a separate class and more lines of code, but dramatically improves maintainability when parameter count exceeds three.Builder vs JavaBeans (Setters):
JavaBeans uses a no-arg constructor and setters. This allows inconsistent state: an object might be used before all required fields are set. Builder enforces required fields in its constructor and produces an immutable object. Trade-off: JavaBeans is simpler for frameworks that require no-arg constructors (like some ORMs or serialization libraries), but Builder is superior for domain logic where consistency matters.
Builder vs Factory:
Factory encapsulates object creation logic, often choosing which subclass to instantiate based on parameters. Builder focuses on step-by-step construction of a single complex object. They can be combined: a factory might return a pre-configured builder. Trade-off: Use Factory when the decision is WHICH type to create. Use Builder when the decision is HOW to configure a known type.
Builder vs Method Chaining on Product:
Why not have
ticket.setSpot(spot).setAttendant(id).finalize()? This exposes setters on the product, violating immutability. Anyone holding a reference could call setters later. Builder isolates mutability to the construction phase. Trade-off: Method chaining on the product is simpler but unsafe if immutability is required.When Builder is Overkill:
First, Object has fewer than three parameters and no validation. A
Second, All parameters are required and order is obvious. A
Third, Framework requires specific constructors. Some serialization frameworks (JSON libraries, ORMs) need no-arg constructors and setters. In this case, use JavaBeans but isolate it to a DTO layer, not domain models.
Fourth, Object is simple and frequently created in tight loops. Builder adds overhead (extra object allocation, method calls). If performance is critical and the object is simple, prefer direct construction. However, this is rare in LLD interviews which prioritize design over micro-optimization.
First, Object has fewer than three parameters and no validation. A
Name class with firstName and lastName does not need a builder. Use a simple constructor.Second, All parameters are required and order is obvious. A
Dimension(length, width, height) with clear semantics does not benefit from a builder.Third, Framework requires specific constructors. Some serialization frameworks (JSON libraries, ORMs) need no-arg constructors and setters. In this case, use JavaBeans but isolate it to a DTO layer, not domain models.
Fourth, Object is simple and frequently created in tight loops. Builder adds overhead (extra object allocation, method calls). If performance is critical and the object is simple, prefer direct construction. However, this is rare in LLD interviews which prioritize design over micro-optimization.
Design Principle: Builder optimizes for CLARITY and SAFETY at the cost of VERBOSITY. If your domain values clear construction and immutability over conciseness, Builder is appropriate. If you are designing a performance-critical data structure with simple construction, skip it.
💡 Key Takeaways
✓Use for four or more parameters with at least two optional
✓Use when validation depends on parameter combinations
✓Use when immutability is required after construction
✓Overkill for simple objects with fewer than three required parameters
✓Builder adds verbosity but improves clarity and safety over alternatives
📌 Examples
1Appropriate: HTTP request with URL, headers, body, timeout, retries
2Overkill: 2D Point with just x and y coordinates
3Appropriate: Email with recipient, subject, body, CC, BCC, attachments