Exercises — Design Patterns — Creational - Singleton, Factory Method, Abstract Factory, Builder, Prototype

Singleton. The rule from the map: "want exactly 1 shared instance ⇒ Singleton". The tell-tale phrase is "two copies would give two different truths" — that is exactly the inconsistent-state problem a single global access point removes. See Singleton.

Factory Method. Symptom = one product whose concrete class is decided by a subclass overriding a creation method. Not Abstract Factory, because we make one product, not a matching family. See Factory Method.

Abstract Factory. The word "match / family / never mismatch" is the fingerprint. One factory object hands out a whole consistent kit. See Abstract Factory.

Builder. Symptom = many (often optional) constructor arguments (the "telescoping constructor" smell). Builder names each step: .addCheese().size("L"). See Builder.

Prototype. Symptom = "copy an existing object" because fresh construction is expensive or you only have a runtime instance to duplicate. See Prototype.

class Logger {
    private Logger() {}                 // block outside `new`
    private static class Holder {       // nested class not loaded yet...
        static final Logger I = new Logger();
    }
    public static Logger getInstance() {
        return Holder.I;                // ...loaded HERE, on first call
    }
}

Lazy: the JVM does not load Holder (and therefore does not run new Logger()) until getInstance() is first called. Thread-safe: the JVM class-loading mechanism guarantees a class is initialized exactly once, even if many threads race — no manual synchronized needed. This beats the naive if (instance == null) check, which two threads can both pass at once and each build an instance.

Extract the new into an overridable method:

abstract class ReportPage {
    abstract Exporter createExporter();   // the hook
    void build() {
        Exporter e = createExporter();     // shared workflow, no concrete class
        e.write();
    }
}
class PdfReportPage extends ReportPage {
    Exporter createExporter() { return new PdfExporter(); }
}
class CsvReportPage extends ReportPage {
    Exporter createExporter() { return new CsvExporter(); }
}

The shared workflow (build) stays in the base class; only the product choice varies via subclass override — exactly the point of Factory Method.

final class HttpRequest {
    private final String url, method; private final int timeout;
    private HttpRequest(Builder b){ url=b.url; method=b.method; timeout=b.timeout; }
    static class Builder {
        private String url, method = "GET"; private int timeout = 30;
        Builder url(String u){ this.url = u; return this; }        // fluent: return this
        Builder method(String m){ this.method = m; return this; }
        Builder timeout(int t){ this.timeout = t; return this; }
        HttpRequest build() {
            if (url == null || url.isEmpty())
                throw new IllegalStateException("url required"); // invariant checked here
            return new HttpRequest(this);
        }
    }
}

Why return this? So calls chain: new Builder().url("x").timeout(5).build(). Why validate in build()? So no half-built or invalid object ever escapes to a client — the invariant "url is non-empty" holds for every finished object.

One bug: this is a shallow copy of center. c.center = this.center copies the reference, so the clone and the original point at the same Point object. Move the clone (c.center.x += 10) and the original moves too — silent corruption. Fix — deep copy the nested mutable field:

c.center = new Point(this.center.x, this.center.y); // fresh Point

The int r is fine to copy directly, because primitives are values, not shared references. Rule: deep-copy every mutable reference-typed field; primitives and immutables are safe to share. See Prototype.

It does not compile — the constructor Logger() is private, so new Logger() is illegal outside the class. That is exactly what we want: the private constructor is the wall that makes "exactly one instance" enforceable rather than a polite request. If the constructor were public, Singleton would be a suggestion, not a guarantee.

Difference: Factory Method varies one product by subclassing (override one method); Abstract Factory varies a family by composition (pass a different factory object at runtime). New product hurts Abstract Factory more: adding createSlider() to the GUIFactory interface forces every concrete factory (WinFactory, MacFactory, …) to implement it — the interface change ripples across the whole family. Factory Method only touches subclasses that care.

• (a) matching theme kit → Abstract Factory (ForestFactory, LavaFactory). They must stay consistent — one factory hands out both enemy and item.
• (b) 12 optional traits → Builder for the enemy. Avoids a 12-argument telescoping constructor; each trait is a named step.
• (c) 1000 near-identical orcs, expensive build → Prototype. Build one orc, then clone() (deep copy) the rest — skip the heavy construction 999 times.
• (d) one GameState → Singleton. Single source of truth; a second copy would desync the game.

Notice they compose cleanly: the Abstract Factory can use a Builder internally, and the objects it returns can be Prototypes. See Abstract Factory, Builder, Prototype, Singleton.

Apply Dependency Injection: instead of code reaching out with GameState.getInstance(), pass a GameState object into each class's constructor. See Dependency Injection. Now a test can pass a fresh, isolated GameState, and production passes the real one. The Singleton's hidden global dependency becomes an explicit, swappable parameter — testable and honest. (Reach for raw Singleton only for truly unique resources you never need to fake.)

Honest verdict: the Holder idiom cannot bend — its guarantee is "exactly one, forever," enforced by the private constructor. That guarantee is now wrong for the requirement. Do not hack a reset() back door (it reintroduces the mutable-global bug the pattern hid). Correct move: drop Singleton and switch to Dependency Injection — make Logger an ordinary class and let the container hand out one shared instance in production and a fresh one in tests. Lesson: a pattern is a tool for a constraint; when the constraint changes, change the pattern.

See the figure below: the fresh copy A' gets its own B', but B' still points at the original C — so mutating C through the clone corrupts the original graph.

Rule (recursive deep copy): a clone is independent only if every mutable object reachable from it is itself freshly copied — copying must recurse all the way down the graph. Stop recursing only at immutable/primitive values (safe to share). Here you must also clone() C inside B's clone.

Interleaving:

1. Thread T1 reads instance → null, passes the check.
2. Before T1 runs instance = new Logger(), the OS switches to T2.
3. Thread T2 reads instance → still null, passes the check.
4. T2 does new Logger() (instance #1); T1 resumes and does new Logger() (instance #2).

Result: two Loggers, both handed out to different callers — the guarantee is broken. Strongest fix: the initialization-on-demand Holder idiom (2.1), because the JVM guarantees a class initializes exactly once with zero lock contention on the read path.

Match the symptom to the pattern ::: 1 shared → Singleton · one product, subclass picks → Factory Method · matching family → Abstract Factory · many optional args → Builder · copy existing → Prototype.