Builder & Prototype Patterns — Interview Questions

How to use this lesson

Builder is used in almost every Java codebase (and generated by Lombok or records), so interviewers look for nuance: validation in build(), immutability, and builders with inheritance. Prototype is rarer, and the best answer shows you know why clone() is discouraged, and what to use instead.

Q1. What is the Builder pattern's purpose, and when do you use it?

Short answer: Builder separates the construction of a complex object from its final representation. You set parts step by step, through named methods, then call build() to get a complete, usually immutable, object. Use it when:

• the object has many parameters, especially optional ones;
• cross-field validation is needed;
• construction happens in stages;
• you want readable call sites in tests and configuration code.

Learn it in depth → Builder Pattern

Q2. What is the Builder pattern, and when would you use it? (Implementation view)

Short answer: The idiomatic Java form is a static nested Builder with fluent setters, and a private constructor on the product that takes the builder:

public final class HttpRequestSpec {
    private final URI uri; private final String method; private final Map<String, String> headers; private final Duration timeout;

    private HttpRequestSpec(Builder b) {
        this.uri = Objects.requireNonNull(b.uri, "uri");
        this.method = b.method;
        this.headers = Map.copyOf(b.headers);
        this.timeout = b.timeout;
    }
    public static Builder builder(URI uri) { return new Builder(uri); }   // required params in the factory

    public static final class Builder {
        private final URI uri; private String method = "GET";
        private final Map<String, String> headers = new LinkedHashMap<>(); private Duration timeout = Duration.ofSeconds(10);
        private Builder(URI uri) { this.uri = uri; }
        public Builder method(String m) { this.method = m; return this; }
        public Builder header(String k, String v) { headers.put(k, v); return this; }
        public Builder timeout(Duration t) { this.timeout = t; return this; }
        public HttpRequestSpec build() {
            if (timeout.isNegative() || timeout.isZero()) throw new IllegalStateException("timeout must be > 0");
            return new HttpRequestSpec(this);
        }
    }
}

Key points to cover:

• Put required parameters in the builder's factory or constructor, so they can't be forgotten.
• Validate in build(), where all the values are known.

Q3. How does Builder differ from Factory?

Short answer: A factory chooses which object (or class) to create, usually in one call. A builder controls how one complex object is assembled, over many calls, with optional parts and final validation. A factory can return a builder (HttpRequest.newBuilder()), which combines both.

Q4. What are the benefits of Builder for complex objects?

Short answer:

• Readable, self-documenting construction.
• No telescoping constructors.
• Immutable products, without a giant constructor.
• A consistent state: the object is only exposed after validation.
• Defaults in one place.
• Evolution: new optional fields don't break existing callers.
• Test data builders make tests expressive.

Costs: more code (reduced by Lombok's @Builder, IDE generation, or records plus "wither" methods), and it's possible to forget required fields unless you enforce them.

Q5. How does method chaining work in a builder?

Short answer: Each setter mutates the builder and returns this, so calls can be chained into a fluent expression. build() ends the chain, and returns the product.

Key points to cover:

• With inheritance, a parent builder's methods return the parent type, which breaks chaining for subclass methods. The fix is the recursive generic ("self type") idiom:

abstract class Notification {
    abstract static class Builder<T extends Builder<T>> {
        String recipient;
        T recipient(String r) { this.recipient = r; return self(); }
        abstract T self();
        abstract Notification build();
    }
}
final class SmsNotification extends Notification {
    static final class Builder extends Notification.Builder<Builder> {
        String senderId;
        Builder senderId(String s) { this.senderId = s; return this; }
        Builder self() { return this; }
        SmsNotification build() { return new SmsNotification(); }
    }
}
// new SmsNotification.Builder().recipient("+91…").senderId("SHOPIN").build();   ← chains cleanly

• Staged (step) builders return different interfaces at each step, so the compiler forces required fields in order.

Q6. Give an example where a builder is preferable to multiple constructors.

Short answer: A server or computer configuration: CPU, RAM, storage type and size, GPU, OS and network options, most of them optional. Constructors for every combination explode (the telescoping constructor anti-pattern), and positional boolean/int arguments are unreadable and error-prone (new Server(16, 64, true, false, 2, true)). A builder names each choice, applies defaults, and validates combinations (for example, "a GPU requires at least 32 GB of RAM").

Server s = Server.builder("c7g.4xlarge")
        .ramGb(64)
        .storage(Storage.nvme(2_000))
        .gpu(Gpu.NONE)
        .build();

Q7. What is the Prototype pattern, and how does it work?

Short answer: Prototype creates new objects by copying a pre-configured instance (the prototype), instead of building from scratch. It's useful when construction is expensive (heavy initialisation, parsing, a remote call), or when you need many slightly varied copies of a template. The client asks the prototype for a copy, then tweaks it.

Key points to cover:

• Real uses: document or report templates, game entity templates, prototype-scoped Spring beans (a similar name, a different idea: a new instance per request, not a copy), and configuration presets.

Q8. What's the difference between shallow and deep cloning in Prototype?

Short answer: A shallow copy duplicates only the top-level fields. Referenced objects are shared, so mutating a nested list through the copy changes the prototype. A deep copy also duplicates the mutable referenced objects, recursively, so the copy is fully independent. Immutable parts (strings, records, LocalDate) can safely stay shared, even in a deep copy.

Q9. How do you implement the Prototype pattern in Java?

Short answer: Prefer a copy constructor, or a copy() method you control, over Cloneable/clone():

public final class ReportTemplate {
    private final String title;
    private final List<Section> sections;               // Section is mutable here

    public ReportTemplate(String title, List<Section> sections) { this.title = title; this.sections = sections; }
    public ReportTemplate copy() {                        // an explicit deep copy of the mutable parts
        return new ReportTemplate(title, sections.stream().map(Section::copy).collect(Collectors.toCollection(ArrayList::new)));
    }
}

ReportTemplate monthly = registry.get("monthly-sales").copy();   // prototype registry

Key points to cover:

• Cloneable works (implement it, override clone() as public, and call super.clone() for the shallow part, then deep-copy the mutable fields), but it has well-known flaws:

  • It bypasses constructors and their invariants.
  • It conflicts with final fields.
  • The checked exception is awkward.
  • Its contract is poorly specified.

  That's why Effective Java recommends copy constructors or factories.

Q10. When would you use Prototype instead of creating a new instance?

Short answer: When:

1. Creation is expensive, and the result can be reused as a template: parsed templates, objects built from database or remote data, precomputed structures.
2. You need many similar objects, with small variations.
3. The concrete class is only known at runtime (a registry of prototypes keyed by name), so the client can't call the right constructor.

Key points to cover:

• If creation is cheap, just use new or a factory. Copying is only a win when construction is costly.

Q11. What are the common pitfalls of Prototype?

Short answer:

• Accidental sharing through shallow copies: nested mutable state changes in both objects.
• Deep copies that are wrong, or incomplete, as the class evolves (new fields forgotten in copy()).
• Cycles in the object graph, where naive deep copies recurse forever.
• Copying identity fields (IDs, version numbers, timestamps) that should be reset.
• Expensive deep copies that erase the performance benefit.
• clone()'s pitfalls: skipped constructors and broken invariants.

Key points to cover:

• Mitigations:
  • Favour immutable components, which never need copying.
  • Write explicit copy methods, with tests that assert independence.
  • Reset identity fields on copy.

Follow-up questions this topic invites — and their answers

Q: What does Lombok's @Builder generate, and what are its caveats? A: A static builder class with fluent setters, and build(). Its caveats: required fields aren't enforced; defaults need @Builder.Default; inheritance needs @SuperBuilder; and you should still add validation (in a constructor, or a @Builder.ObtainVia/custom build()).

Q: Can records use builders? A: Yes. Hand-write a nested builder, or use a library like RecordBuilder. For small records, "wither" methods (withTimeout(...)) returning new instances are often enough.

Q: Is StringBuilder a Builder-pattern example? A: Loosely. It incrementally assembles a String and finishes with toString(), and it uses method chaining, but it doesn't validate or separate representations the way the GoF Builder does.

Q: How does Prototype relate to Spring's prototype scope? A: Spring's prototype scope creates a new instance (with a fresh construction and injection) on each request. It doesn't copy an existing object. It's closer to a factory than to the GoF Prototype.