Code10x
Creation patternseasy0-2 years

A teammate writes `@Service class RequestCounter { private int count; void increment() { count++; } }` and calls it "just a singleton, Spring makes that safe." Does it?

No — Spring made the dependency safe (visible in a constructor, substitutable in a test), it never made the instance's mutable fields safe. A Spring bean is a singleton by default, meaning exactly one RequestCounter object is created and handed to every controller that asks for it, so count is one int shared by however many request threads are running concurrently. count++ is not atomic — it is a read, an add and a write, and two threads interleaving those three steps lose increments, silently, with no exception. Spring's improvement over the hand-written singleton was removing global access (getInstance()), not removing shared mutable state; a bean with a non-final, non-thread-safe field is still a singleton with everything a singleton's mutable state has always cost, and it passes every single-threaded test written against it.

The lesson behind it →
Next You're handed `new GzipOutputStream(new BufferedOutputStream(new FileOutputStream(path)))` in a code review with no comments. What pattern is this, how do you recognise it on sight, and what would adding "encrypted" as a fourth option cost under this design versus under a subclassing design?
More on Creation patterns
A `Rectangle` builder validates each dimension in its own setter — `width(int w) { if (w <= 0) throw ...; this.w = w; return this; }` — and the object still ends up with an invalid combination in production: width and height set fine individually, but the resulting rectangle violates a rule that only makes sense once both are known ("an expedited shipment needs an address", in the lesson's own example). What's the actual rule for where builder validation belongs, and why does per-setter validation miss this?