Summary

Quick reference for creational patterns — use the tables below, then the Singleton concurrency note and worked contrast. This is a cheat-sheet, not a substitute for the full pattern pages.

Pattern taxonomy recap

Family	What it solves	Canonical patterns
Creational	How objects are instantiated and who decides the concrete type	Singleton, Factory Method, Abstract Factory, Builder, Prototype
Structural	How classes/objects are composed into larger structures	Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral	How objects communicate and how responsibilities are distributed	Observer, Strategy, Command, State, Template Method, Iterator, Mediator, Memento, Chain of Responsibility, Visitor

Creational patterns: when to use

Pattern	Use when	Skip when
Singleton	Exactly one shared instance is a genuine invariant	Statelessness, testability, or dependency injection are more important
Factory Method	A class cannot know the exact subtype it must create	There is only one concrete product and no realistic second variant
Abstract Factory	You need families of related products	Only one product family exists
Builder	Many optional parameters or ordered construction steps	The object has one or two simple fields
Prototype	Object creation is cheaper by copying than by construction	Deep-copy semantics are complex or unclear

Singleton: the concurrency footgun (must know)

Naive lazy init is a data race under multi-threaded first access:

// BROKEN under concurrency — two threads can both see instance == null
private static Config instance;
static Config get() {
    if (instance == null) instance = new Config(); // race
    return instance;
}

• Double-checked locking only works if the field is volatile (Java memory model); without it, a thread can observe a partially constructed object.
• Safer defaults: initialization-on-demand holder, enum singleton, or — best for testability — do not use Singleton: register one instance in a DI container and inject it.
• Cons that matter in production: hidden global mutable state, hard unit tests, and the race above — not just “harder to test.”

Worked contrast: Factory Method vs Simple Factory

// Simple Factory — one class switches on a type (not the GoF pattern)
Document open(String kind) {
    return switch (kind) {
        case "pdf" -> new PdfDocument();
        case "docx" -> new DocxDocument();
        default -> throw new IllegalArgumentException(kind);
    };
}

// Factory Method — subclasses decide the concrete product; open-closed for new formats
abstract class Application {
    abstract Document createDocument(); // factory method
    void newDocument() { Document d = createDocument(); d.open(); }
}
class PdfApp extends Application {
    Document createDocument() { return new PdfDocument(); }
}

Prefer Factory Method when callers should not know the concrete type and new products arrive as new subclasses. Prefer Simple Factory when the set of types is closed and small.

Interview trap box

• "Singleton is always good for shared resources." It is not — it hides dependencies, complicates tests, creates global mutable state, and naive lazy init races.
• "Factory is just a method that returns new." The point is decoupling the caller from the concrete type, not the syntax.
• "Builder is only for objects with many fields." The deeper signal is an immutable object assembled in discrete steps; field count alone is not enough.
• Confusing Factory Method and Abstract Factory. Factory Method lets subclasses choose the concrete class; Abstract Factory creates whole families of related objects.

I just read a lesson on **Summary** (OO & Low-Level Design) and want to truly understand it. Explain Summary from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Summary** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Summary** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Summary** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.