DEV Community: manoj shirgire

# Don't Rebuild It. Photocopy It.

manoj shirgire — Sun, 07 Jun 2026 05:44:38 +0000

Most explanations of the Prototype pattern start and end with "it lets you clone objects." That tells you what it does, not why you'd ever want it. The real reason has nothing to do with cloning for its own sake — it's about the expensive work that goes into building an object in the first place.

The benefit, stated plainly

Sometimes building an object is expensive. Not the object itself — the work required to fill it. A heavy computation. A slow database read. Three network calls to outside services. A scoring model that takes two seconds to run. And the result of all that work gets stored inside the object.

Now imagine you need a second object that is almost the same. Do you redo the two seconds of work? Or do you take the one you already built — which already has the expensive result inside it — and copy it?

That is the Prototype pattern. When building an object involves heavy work whose result is stored in the object, you pay that cost once, then copy the finished object instead of rebuilding from scratch. The second object, and the third, and the tenth, come almost for free.

Where the cost actually hurts

Let me show the expensive part honestly, because a toy example with an empty constructor hides the whole point.

class CreditReport {
    String customerId;
    int score;
    List<String> riskFactors;

    CreditReport(String customerId) {
        this.customerId = customerId;
        // EXPENSIVE: pulls from three credit bureaus and runs a scoring
        // model. Takes about two seconds every time it runs.
        this.score = runExpensiveScoringModel(customerId);
        this.riskFactors = fetchFromCreditBureaus(customerId);
    }
}

Suppose you need five "what-if" variations of one customer's report — same base data, each with one number nudged for a scenario.

Without the Prototype pattern

Every variation calls the constructor, so the two-second work runs every single time:

CreditReport base      = new CreditReport("CUST-001");  // ~2 seconds
CreditReport scenarioA = new CreditReport("CUST-001");  // ~2 seconds AGAIN
CreditReport scenarioB = new CreditReport("CUST-001");  // ~2 seconds AGAIN
CreditReport scenarioC = new CreditReport("CUST-001");  // ~2 seconds AGAIN
CreditReport scenarioD = new CreditReport("CUST-001");  // ~2 seconds AGAIN

scenarioA.score += 20;
scenarioB.score -= 50;
scenarioC.score += 10;
scenarioD.score -= 30;

Five objects, roughly ten seconds — and almost all of it spent recomputing a result you already had after the first call.

With the Prototype pattern

Give the object a copy() method that carries the already-computed result over, and skip the expensive constructor for every copy:

class CreditReport {
    String customerId;
    int score;
    List<String> riskFactors;

    CreditReport(String customerId) {
        this.customerId = customerId;
        this.score = runExpensiveScoringModel(customerId);   // the ~2s work
        this.riskFactors = fetchFromCreditBureaus(customerId);
    }

    // A second, private constructor that does NO expensive work.
    private CreditReport() { }

    // The photocopier: hand back an independent copy, expensive result included.
    CreditReport copy() {
        CreditReport c = new CreditReport();         // no bureau calls, no model run
        c.customerId  = this.customerId;
        c.score       = this.score;                  // reuse the computed score
        c.riskFactors = new ArrayList<>(this.riskFactors);  // (note this line)
        return c;
    }
}

CreditReport base      = new CreditReport("CUST-001");  // ~2 seconds, paid ONCE

CreditReport scenarioA = base.copy();  scenarioA.score += 20;   // instant
CreditReport scenarioB = base.copy();  scenarioB.score -= 50;   // instant
CreditReport scenarioC = base.copy();  scenarioC.score += 10;   // instant
CreditReport scenarioD = base.copy();  scenarioD.score -= 30;   // instant

About two seconds total instead of ten. The expensive work is already sitting inside base, so each copy just carries it along. That is the prize.

The honest part — copying isn't free

Be clear about one thing: the lines inside copy() do run, every time.

c.customerId  = this.customerId;
c.score       = this.score;
c.riskFactors = new ArrayList<>(this.riskFactors);

These cost CPU. The new ArrayList<>(...) line actually allocates a fresh list and copies its elements in. Prototype does not make objects appear out of nothing.

The point is the comparison. These field copies are trivial — fractions of a microsecond — next to the two-second bureau pull and model run you are avoiding. You are not getting copies for free; you are trading a tiny, cheap copy for a huge, expensive rebuild. When the rebuild is genuinely expensive, that trade is a bargain. When the constructor is cheap and does nothing, this trade buys you nothing at all — so don't bother with Prototype there.

The trap that bites everyone — shallow vs deep copy

Look again at that one line:

c.riskFactors = new ArrayList<>(this.riskFactors);   // a NEW list

That new ArrayList<>(...) matters enormously. Suppose you'd written the lazy version instead:

c.riskFactors = this.riskFactors;   // the SAME list object

Now every copy points at the same underlying list. So this happens:

scenarioA.riskFactors.add("late-payment-2024");
// scenarioB, scenarioC, and base now ALL show that risk factor too.

You thought you photocopied the report, but all the copies were secretly stapled to one shared page — write on it through any copy and everyone changes. That is the difference between a shallow copy (duplicates the top object but shares the nested objects inside it) and a deep copy (duplicates the nested objects too, so each copy is truly independent).

The real work of Prototype isn't the cloning itself — it's making the copy deep enough that copies don't secretly share their mutable parts. For one list inside, that's a single careful line. For a deeply nested object, it's genuinely fiddly, and it's the main reason hand-rolled cloning earns a bad reputation.

A small Java note: prefer a plain copy() method or a copy constructor like new CreditReport(base) over implementing the old Cloneable interface — it's clearer about exactly what gets copied, and you stay in control of the shallow-versus-deep decision.

When to use it — and when not to

Reach for Prototype when at least one of these is true:

Building the object is genuinely expensive — heavy computation, a database or network read, lots of validation — and you'd rather pay that once.
You need many objects that are mostly identical, with small variations each.
You want to snapshot an object's current state and branch new variations from it.

Skip it when objects are cheap and simple to build. If new Point(x, y) is the whole story, a copy method is just indirection that hides nothing. The pattern earns its place only when construction is costly, or the near-identical-copies problem is real.

The one sentence to remember

Prototype is a photocopier: when building an object takes expensive work whose result is stored inside it, build one, then copy it instead of rebuilding from scratch — and the only catch is making the copy deep enough that the copies don't secretly share their parts.

The Pen That Taught Me the Factory Pattern

manoj shirgire — Sun, 07 Jun 2026 04:56:55 +0000

For a long time, the Factory pattern felt like ceremony to me — an extra class that did nothing my code couldn't already do. Then I thought about ten people and a pen, and it finally clicked. Let me walk you through it.

Ten people, ten pens

Imagine ten people in an office. All of them need to write something. So you give them an instruction:

"Make your own pen, fill it with blue ink, and start writing."

Everyone follows it. Ten people build a pen, fill it with blue, and get to work. In code, each of them is doing this:

Pen pen = new Pen("blue");   // I build it myself
pen.write();

It works. Everyone is writing. Life is good — until the requirement changes.

"Actually, make it red"

Now the instruction changes: stop using blue, use red.

What happens? Every one of the ten people has to personally go to the market, buy red ink, come back, and refill their pen. Ten trips. Ten refills. And here's the dangerous part — if even one person forgets, they keep writing in blue. Nobody notices until the page comes out wrong.

// Every single person must now find and change this line
Pen pen = new Pen("red");

Look at what one small change just cost you:

Ten separate trips to the market — repeated effort.
Ten chances to forget — repeated risk of error.
No easy way to confirm everyone actually switched.

This is the real-world pain. The change itself (blue to red) is tiny. The problem is that the knowledge of how to make a pen is copied into ten heads, so changing it means disturbing all ten.

The pen-maker

So you do something simple. You appoint one person — the pen-maker — and give them the job of building pens. Now nobody makes their own pen. Everyone just walks up and says:

"Give me a pen."

// The pen-maker — the only one who knows how a pen is built
class PenMaker {
    Pen givePen() {
        return new Pen("blue");
    }
}

// Each of the ten people now simply asks
Pen pen = penMaker.givePen();   // "give me a pen"
pen.write();

The pen-maker is the Factory. That's the whole pattern. It isn't a clever trick — it's just one person who holds the knowledge of how to build the thing, so everyone else can stop holding it.

Now watch the same change

Blue to red, one more time. Where does the change happen now?

class PenMaker {
    Pen givePen() {
        return new Pen("red");   // the only line that changes
    }
}

One line. One place. The pen-maker switches to red, and from that moment everyone who asks for a pen gets red — without going anywhere, without changing anything, without even knowing it happened. They still just say "give me a pen."

Ten trips became one. Ten chances to forget became one. That is what the Factory pattern buys you.

The full picture, both ways

Snippets are easy to nod along to, so here is the whole thing written out — all ten people, both versions — so you can count the change sites with your own eyes.

First, the pen itself. This part is the same in both versions:

// A pen is built with one ingredient: the ink colour.
class Pen {
    private String inkColor;

    Pen(String inkColor) {
        this.inkColor = inkColor;
    }

    void write() {
        System.out.println("Writing in " + inkColor);
    }
}

Without a pen-maker

Every person builds their own pen, so the colour "blue" is typed into all ten places:

class Office {
    void person1()  { Pen p = new Pen("blue"); p.write(); }
    void person2()  { Pen p = new Pen("blue"); p.write(); }
    void person3()  { Pen p = new Pen("blue"); p.write(); }
    void person4()  { Pen p = new Pen("blue"); p.write(); }
    void person5()  { Pen p = new Pen("blue"); p.write(); }
    void person6()  { Pen p = new Pen("blue"); p.write(); }
    void person7()  { Pen p = new Pen("blue"); p.write(); }
    void person8()  { Pen p = new Pen("blue"); p.write(); }
    void person9()  { Pen p = new Pen("blue"); p.write(); }
    void person10() { Pen p = new Pen("blue"); p.write(); }
}

Now change blue to red. You must find and fix all ten lines:

class Office {
    void person1()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person2()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person3()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person4()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person5()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person6()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person7()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person8()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person9()  { Pen p = new Pen("red"); p.write(); }   // changed
    void person10() { Pen p = new Pen("red"); p.write(); }   // changed
}

Ten edits. Miss one, and that person quietly keeps writing in blue.

With a pen-maker

The colour is typed in exactly one place — inside the pen-maker. Nobody else mentions it:

// The pen-maker — the only one who knows how a pen is built.
class PenMaker {
    Pen givePen() {
        return new Pen("blue");   // the single source of the colour
    }
}

class Office {
    private PenMaker penMaker = new PenMaker();

    void person1()  { Pen p = penMaker.givePen(); p.write(); }
    void person2()  { Pen p = penMaker.givePen(); p.write(); }
    void person3()  { Pen p = penMaker.givePen(); p.write(); }
    void person4()  { Pen p = penMaker.givePen(); p.write(); }
    void person5()  { Pen p = penMaker.givePen(); p.write(); }
    void person6()  { Pen p = penMaker.givePen(); p.write(); }
    void person7()  { Pen p = penMaker.givePen(); p.write(); }
    void person8()  { Pen p = penMaker.givePen(); p.write(); }
    void person9()  { Pen p = penMaker.givePen(); p.write(); }
    void person10() { Pen p = penMaker.givePen(); p.write(); }
}

Now change blue to red. There is only one line in the whole program that even mentions the colour:

class PenMaker {
    Pen givePen() {
        return new Pen("red");   // the only line that changes
    }
}

The ten people are not touched. They never said "blue," so there is nothing in them to find, fix, or forget. Ten edits became one.

The honest part nobody tells you

The Factory does not delete the work. Somebody still has to change blue to red. The pen-maker still makes that change. The market trip doesn't vanish — it just gets made once, by one person, instead of ten times by ten people.

So if a colleague says, "but the pen-maker still had to change it!" — they're right, and that's not a flaw. Your answer is simply: yes, once, instead of ten times. That's the entire point.

The one sentence to remember

A Factory is a pen-maker: one place that holds the knowledge of how to build something, so that when the way of building it changes, only that one place has to relearn — and everyone who just needs a finished pen is never disturbed.