Code10x
SOLIDmedium3-5 years

A teammate writes `class ReadOnlyOrderRepository extends JpaOrderRepository { public Order save(Order o) { throw new UnsupportedOperationException(); } }` to enforce that a reporting service can't accidentally write. It compiles cleanly and passes code review. What's actually wrong with it, and what should the fix look like?

It's a Liskov substitution violation: ReadOnlyOrderRepository is-a JpaOrderRepository by the type system, so every service that accepts a JpaOrderRepository and calls save on it is now allowed, by the compiler, to be handed this one — and it throws at run time, in whatever code path happens to call save, which is exactly the path nobody's test exercised. ReadOnlyOrderRepository promised the full JpaOrderRepository contract by extending it and delivers less: a caller cannot tell from the type alone that save is a trap. The fix the lesson gives directly: when you find yourself wanting to remove a capability from a subtype rather than add one, the relationship is not inheritance at all — it should be a separate, narrower interface (OrderReader, say, with just the read methods and no save) that the read-only service depends on, so the type system itself makes it impossible to call save on something that was never meant to support it, rather than making it compile and fail later.

The lesson behind it →
PreviousA `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?Next A `discount(Order o)` method has grown to five `if`/`else if` branches over three sprints, and the newest branch broke a case that was working last week. The team's instinct is "add a comment warning about branch order." What does open/closed say the actual fix is, and when would adding a sixth `else if` still be the right call instead?
More on SOLID
A `discount(Order o)` method has grown to five `if`/`else if` branches over three sprints, and the newest branch broke a case that was working last week. The team's instinct is "add a comment warning about branch order." What does open/closed say the actual fix is, and when would adding a sixth `else if` still be the right call instead?Precisely why can `javac` catch a stronger precondition on an overloaded method's parameter types but not a stronger precondition on an override's *behavior* — and what, exactly, is `invokevirtual` doing at the bytecode level that makes an LSP violation a purely run-time phenomenon?