Design Patterns Terminology — Interview Reference

Why this matters in interviews

Senior Java interviews routinely ask you to name patterns by category, explain trade-offs between similar patterns (Decorator vs inheritance, Proxy vs Decorator), and cite concrete JDK examples — not just define them. Interviewers use pattern knowledge as a proxy for design sense: they want to know whether you reach for the right tool and can explain why the JDK itself made the choices it did. Knowing the GoF taxonomy cold, plus the thread-safety nuances of Singleton and the brokenness of Cloneable, separates strong senior candidates from mid-level ones.

Concept

Pattern Categories

---

Creational Patterns

---

Structural Patterns

---

Behavioral Patterns

---

JDK Pattern Examples

---

Key rules / gotchas

• Enum singleton is serialization-safe by default: A regular singleton with a readResolve() override can still be broken via reflection; an enum constant cannot — the JVM prevents multiple instances at the bytecode level.
• volatile is mandatory in DCL: Without volatile, the JIT is free to reorder the write to instance before the constructor finishes, so another thread can observe a non-null but partially initialized object.
• Cloneable does not declare clone(): Object.clone() is protected and throws a checked exception. You must override it as public and cast the result — it is universally regarded as a design mistake. Prefer copy constructors or static factory methods.
• Decorator and Proxy look identical structurally: The difference is intent — Decorator adds behavior, Proxy controls access. Ask yourself: "Am I enriching the object or gatekeeping it?"
• Composite vs Decorator: Composite composes the same type into a tree (part-whole hierarchy); Decorator composes the same type in a linear chain (wrapping to add behavior). Both use recursive composition but for different purposes.
• Spring AOP proxy selection: If the target bean implements at least one interface, Spring defaults to a JDK dynamic proxy (interface-based); if there is no interface, it falls back to CGLIB which subclasses the concrete class at runtime. This matters because CGLIB cannot proxy final classes or final methods.
• Observer push model can couple subject to observer: Sending a fat event object forces observers to depend on types they may not need; the pull model keeps the event lean but requires observers to reach back into the subject.
• Telescoping constructor anti-pattern: Having many overloaded constructors with increasing optional parameters is the smell that Builder cures. Builder also enables immutable objects (all fields set before build() returns).
• Flyweight intrinsic vs extrinsic state: Flyweight only works when a large portion of object state is identical across instances (intrinsic/shared). Extrinsic state that varies per use-site must be passed in by the caller, never stored in the flyweight.
• Template Method vs Strategy: Template Method uses inheritance to vary steps (tight coupling to base class); Strategy uses composition to swap the whole algorithm (looser coupling, more flexible). Prefer Strategy when the algorithm is likely to change at runtime.

---

Code example

import java.util.ArrayList;
import java.util.List;

public class JavaLabRunner {

    // ─── 1. BUILDER PATTERN ────────────────────────────────────────────────────

    static final class QueryConfig {
        private final String table;       // mandatory
        private final int    limit;       // optional (default 100)
        private final boolean readOnly;   // optional (default false)

        private QueryConfig(Builder b) {
            this.table    = b.table;
            this.limit    = b.limit;
            this.readOnly = b.readOnly;
        }

        @Override public String toString() {
            return "QueryConfig{table='" + table + "', limit=" + limit
                    + ", readOnly=" + readOnly + "}";
        }

        static final class Builder {
            // mandatory
            private final String table;
            // optional — defaults set here
            private int     limit    = 100;
            private boolean readOnly = false;

            Builder(String table) {
                if (table == null || table.isBlank())
                    throw new IllegalArgumentException("table must not be blank");
                this.table = table;
            }

            Builder limit(int limit)        { this.limit    = limit;    return this; }
            Builder readOnly(boolean ro)    { this.readOnly = ro;       return this; }

            QueryConfig build()             { return new QueryConfig(this); }
        }
    }

    // ─── 2. STRATEGY PATTERN ───────────────────────────────────────────────────

    @FunctionalInterface
    interface SortStrategy {
        void sort(List<Integer> list);
    }

    static final class BubbleSort implements SortStrategy {
        @Override public void sort(List<Integer> list) {
            int n = list.size();
            for (int i = 0; i < n - 1; i++)
                for (int j = 0; j < n - i - 1; j++)
                    if (list.get(j) > list.get(j + 1)) {
                        int tmp = list.get(j);
                        list.set(j, list.get(j + 1));
                        list.set(j + 1, tmp);
                    }
        }
        @Override public String toString() { return "BubbleSort"; }
    }

    static final class InsertionSort implements SortStrategy {
        @Override public void sort(List<Integer> list) {
            int n = list.size();
            for (int i = 1; i < n; i++) {
                int key = list.get(i), j = i - 1;
                while (j >= 0 && list.get(j) > key) {
                    list.set(j + 1, list.get(j--));
                }
                list.set(j + 1, key);
            }
        }
        @Override public String toString() { return "InsertionSort"; }
    }

    static final class Sorter {
        private SortStrategy strategy;
        Sorter(SortStrategy strategy)          { this.strategy = strategy; }
        void setStrategy(SortStrategy strategy){ this.strategy = strategy; }
        void sort(List<Integer> list) {
            System.out.println("  Using strategy: " + strategy);
            strategy.sort(list);
        }
    }

    // ─── 3. DECORATOR PATTERN ──────────────────────────────────────────────────

    interface TextProcessor {
        String process(String input);
    }

    // Concrete component
    static final class PlainText implements TextProcessor {
        @Override public String process(String input) { return input; }
    }

    // Base decorator — holds a reference to another TextProcessor
    static abstract class TextDecorator implements TextProcessor {
        protected final TextProcessor wrapped;
        TextDecorator(TextProcessor wrapped) { this.wrapped = wrapped; }
    }

    static final class UpperCaseDecorator extends TextDecorator {
        UpperCaseDecorator(TextProcessor wrapped) { super(wrapped); }
        @Override public String process(String input) {
            return wrapped.process(input).toUpperCase();
        }
    }

    static final class TrimDecorator extends TextDecorator {
        TrimDecorator(TextProcessor wrapped) { super(wrapped); }
        @Override public String process(String input) {
            return wrapped.process(input.trim());
        }
    }

    static final class ExclamationDecorator extends TextDecorator {
        ExclamationDecorator(TextProcessor wrapped) { super(wrapped); }
        @Override public String process(String input) {
            return wrapped.process(input) + "!!!";
        }
    }

    // ─── MAIN ──────────────────────────────────────────────────────────────────

    public static void main(String[] args) {

        // --- Builder ---
        System.out.println("=== Builder Pattern ===");
        QueryConfig cfg = new QueryConfig.Builder("users")
                .limit(50)
                .readOnly(true)
                .build();
        System.out.println(cfg);

        QueryConfig cfgDefaults = new QueryConfig.Builder("orders").build();
        System.out.println(cfgDefaults);

        // --- Strategy ---
        System.out.println("\n=== Strategy Pattern ===");
        List<Integer> data1 = new ArrayList<>(List.of(5, 2, 8, 1, 9));
        List<Integer> data2 = new ArrayList<>(List.of(5, 2, 8, 1, 9));

        Sorter sorter = new Sorter(new BubbleSort());
        sorter.sort(data1);
        System.out.println("  Result: " + data1);

        sorter.setStrategy(new InsertionSort());   // swap strategy at runtime
        sorter.sort(data2);
        System.out.println("  Result: " + data2);

        // Comparator as Strategy (JDK example)
        List<String> words = new ArrayList<>(List.of("banana", "apple", "cherry"));
        words.sort((a, b) -> a.length() - b.length());  // lambda = inline Strategy
        System.out.println("  Sorted by length: " + words);

        // --- Decorator ---
        System.out.println("\n=== Decorator Pattern ===");
        // Stack decorators: Trim → UpperCase → Exclamation
        TextProcessor pipeline = new ExclamationDecorator(
                                     new UpperCaseDecorator(
                                         new TrimDecorator(
                                             new PlainText())));
        String result = pipeline.process("  hello world  ");
        System.out.println("  Input : '  hello world  '");
        System.out.println("  Output: '" + result + "'");

        // JDK analogy (prints, not constructs actual streams to keep it runnable)
        System.out.println("  JDK analogy: new BufferedReader(new InputStreamReader(stream))");
        System.out.println("  Each layer is a decorator — same Reader interface, added behavior.");
    }
}

Interview questions you should be able to answer

• Q: Why does Effective Java recommend enum singleton over Double-Checked Locking?

  Enum singleton is guaranteed by the JVM to have exactly one instance, is immune to reflection attacks (newInstance() on an enum throws IllegalArgumentException), and is automatically serialization-safe without any readResolve() override. DCL requires volatile (easy to forget), a synchronized block, a null-check inside and outside the lock, and a hand-rolled readResolve() to prevent deserialization from creating a second instance — far more boilerplate with more ways to go wrong.

• Q: How does Spring AOP decide whether to use a JDK dynamic proxy or a CGLIB proxy, and why does it matter?

  Spring uses a JDK dynamic proxy when the target bean implements at least one interface — the proxy implements the same interface(s) and delegates. When there is no interface, Spring generates a CGLIB subclass of the concrete class at runtime. It matters because CGLIB cannot proxy final classes or final methods (subclassing is blocked), and CGLIB-proxied beans require a no-arg constructor for the generated subclass. You can force CGLIB with @EnableAspectJAutoProxy(proxyTargetClass = true).

• Q: When should you prefer Decorator over inheritance for extending behavior?

  Decorator should be preferred when you need to compose behaviors in flexible, stackable combinations at runtime without committing to a fixed class hierarchy. Inheritance hard-codes the combination at compile time and causes a class explosion as the number of combinations grows (e.g., BufferedEncryptedCompressedReader as a single class). Decorator keeps each concern in its own small class, and callers assemble the stack they need. Inheritance is only preferable when the extended behavior is a true "is-a" specialization unlikely to change.

• Q: Why is Cloneable considered broken in Java?

  Cloneable is a marker interface that does not declare the clone() method, so implementing it gives you no compile-time guarantee of a usable API. Object.clone() is protected and throws a checked CloneNotSupportedException unless Cloneable is implemented, forcing awkward override boilerplate. The default implementation performs only a shallow copy, which silently shares mutable nested objects between the original and clone. There is no clean mechanism for deep copying, and the whole design pre-dates generics and lambdas. Effective Java recommends using a copy constructor (new MyClass(other)) or a static factory method instead.

• Q: What is the structural difference between Composite and Decorator, and how do you tell them apart?

  Both patterns rely on a component interface implemented by both the "wrapper" and the "core" object, enabling recursive composition. The distinction is in purpose and tree shape: Composite builds a tree of uniform nodes to represent a part-whole hierarchy (a Directory is-a FileSystemEntry and contains other FileSystemEntry objects); Decorator builds a linear chain where each wrapper adds a single behavior increment (a BufferedReader wraps a Reader and adds buffering). Composite nodes know about their children; Decorators are agnostic to what they wrap beyond the shared interface.

• Q: Name a concrete JDK example of the Template Method pattern and describe what the template method defines.

  HttpServlet.service(HttpServletRequest, HttpServletResponse) is the template method. It reads the HTTP method from the request and dispatches to doGet(), doPost(), doPut(), etc. The skeleton — parse method, dispatch, handle 405 for unsupported methods — is fixed in service(). Subclasses override only the specific handler methods they need. AbstractList is another example: iterator() and listIterator() are template methods whose implementations call the abstract primitives get(int index) and size(), which concrete subclasses must provide.

---

Further reading

• Gamma, Helm, Johnson, Vlissides — Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994) — the original GoF catalog
• Bloch, Joshua — Effective Java, 3rd Edition, Items 3 (singleton), 13 (clone), 17 (immutability with Builder), 18 (composition over inheritance)
• Refactoring.Guru — https://refactoring.guru/design-patterns/java — concise pattern summaries with Java code
• Baeldung — https://www.baeldung.com/design-patterns-series — practical Spring-context pattern examples
• Oracle Java Docs — java.lang.reflect.Proxy, java.util.Iterator, java.util.Comparator — see the Javadoc "Implementation Note" sections for pattern commentary
• Spring Framework Reference — https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#aop — AOP proxy mechanism (JDK vs CGLIB)