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

Before we begin, three plain-word anchors so no term sneaks in undefined:

Step 1 — The naked new (the problem we are attacking)

WHAT. The client says, literally, Button b = new WinButton();.

WHY look here first. This one line secretly welds the client to the concrete class WinButton. If tomorrow you need a MacButton, you must hunt down and edit every such line. There is no wall — the customer is standing inside the workshop.

PICTURE. In the figure the orange client arrow reaches straight through to the magenta concrete box. That direct arrow is the coupling we want to break.

$\underset{\text{what client holds (interface)}}{\underbrace{\text{Button b}}}=\underset{\text{the build action}}{\underbrace{\text{new}}}\underset{\text{concrete class — the leak}}{\underbrace{\text{WinButton()}}}$

The leak is the last term: a concrete name written inside client code.

Step 2 — First wall: hide the new behind a method (Factory Method is born)

WHAT. Move the new out of the client and into an overridable method createButton(). The client now calls the method, not the constructor.

WHY this move and not another. A method is the smallest thing a subclass can replace. By turning the fixed new WinButton() into a call createButton(), we make the choice of class a thing a subclass decides — the client's workflow no longer names any concrete class.

PICTURE. The straight arrow from Step 1 is now cut by a wall. The client points at the wall's slot (createButton); behind the wall a subclass drops in the concrete box.

abstract class Dialog {
    abstract Button createButton();   // the slot in the wall
    void render() {                   // client workflow — no concrete name
        Button b = createButton();
        b.draw();
    }
}
class WinDialog extends Dialog {
    Button createButton() { return new WinButton(); } // the ONE place `new` lives
}

$\underset{\text{the hook}}{\underbrace{\text{createButton()}}}⟶\underset{\text{decided by the subclass}}{\underbrace{\text{new WinButton()}}}$

This is Factory Method: one product, subclass chooses the class.

Step 3 — The wall must hand out a matching set (Abstract Factory is born)

WHAT. Group several such hooks — createButton() and createCheckbox() — into one object called a factory.

WHY we needed to grow. Factory Method gives one product. But a Windows look needs button and checkbox that match. If two separate factory methods could be mixed, you might get a Windows button beside a Mac checkbox — a mismatch. Bundling them in one factory object guarantees they come from the same family.

PICTURE. Now the wall has two slots, and behind it sits a single coloured factory box that feeds both slots from the same palette — never mixing colours.

interface GUIFactory {              // the family, behind the wall
    Button   createButton();
    Checkbox createCheckbox();
}
class WinFactory implements GUIFactory {
    public Button   createButton()   { return new WinButton(); }
    public Checkbox createCheckbox() { return new WinCheckbox(); } // same family
}

$\underset{\text{one object}}{\underbrace{\text{GUIFactory}}}=\{\underset{\text{part 1}}{\underbrace{\text{createButton}}},\underset{\text{part 2}}{\underbrace{\text{createCheckbox}}}{\}}_{\text{guaranteed same family}}$

This is Abstract Factory. Difference from Step 2: Factory Method varies by subclass; Abstract Factory varies by swapping the whole factory object — you pass a different one at runtime.

Step 4 — When building is complicated, add a step-by-step wall (Builder is born)

WHAT. Instead of one giant constructor new Pizza(true,false,true,...), chain named steps and finish with build().

WHY a new shape of wall. The Factory walls above choose which class. Builder solves a different pain: a single class with too many optional parts. A row of booleans is unreadable and easy to mis-order. Naming each step (addCheese()) makes intent obvious, and delaying the finished object until build() lets us validate and keep the result immutable (unchangeable after creation).

PICTURE. A conveyor belt: raw parts enter, each labelled station adds one part, and only the final build() gate lets the sealed object out. No half-built object escapes mid-belt.

Pizza p = new Pizza.Builder()
    .size("L")      // step
    .addCheese()    // step
    .addOlives()    // step
    .build();       // gate: validate + seal

$\underset{\text{ordered, named steps}}{\underbrace{\text{.size().addCheese().addOlives()}}}\stackrel{\text{build()}}{\to }\underset{\text{validated, immutable}}{\underbrace{\text{Pizza}}}$

This is Builder. It is not a fancy setter: setters mutate an existing object; Builder produces a new sealed one.

Step 5 — When building is expensive, copy instead of rebuild (Prototype is born)

WHAT. Keep one finished object as a template and produce new ones by clone() instead of new.

WHY yet another move. Steps 2–4 all still build from scratch. But if building means a heavy DB load or parsing, doing it 1000 times is wasteful — and sometimes you only have a runtime object, not its recipe. Copying sidesteps construction entirely.

PICTURE. A photocopier: the violet original goes in, an identical copy comes out. The subtle danger is drawn too — a shallow copy shares the same nested box (an arrow from both copies to one inner object), so editing one corrupts the other.

interface Shape { Shape clone(); }
class Circle implements Shape {
    int r;
    public Shape clone() { Circle c = new Circle(); c.r = this.r; return c; }
}

$\underset{\text{copy, not build}}{\underbrace{\text{clone()}}}:\underset{\text{template}}{\underbrace{\text{original}}}⟶\underset{\text{same field values}}{\underbrace{\text{new copy}}}$

This is Prototype. Edge case (its own warning): a shallow copy duplicates only the top box and shares nested mutable fields — you must write a deep copy for those.

Step 6 — The degenerate case: what if you want exactly one? (Singleton)

WHAT. Sometimes the right count of objects is not "many" but one. Make the constructor private so no one can new, and hand the single instance out through a static method.

WHY it belongs here. Every pattern above assumes the client may make many. Singleton is the boundary case where the answer to "how many?" is one — a config registry, a logging hub. It is the wall turned all the way up: the workshop door is locked; you get the one object that already exists.

PICTURE. One vending machine for the whole building; every arrow from every client points to the same single box.

class Logger {
    private Logger() {}                                  // door locked
    private static class Holder { static final Logger I = new Logger(); }
    public static Logger getInstance() { return Holder.I; } // one exit
}

The one-picture summary

The whole page is one question asked five times — "how many, and how hard to build?" — with the wall reshaped to fit each answer.

See also the Design Principles index, and where the wall leads next: Structural Patterns, Behavioral Patterns.