Code10x
SOLIDhard5-8 years

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?

javac's override check operates purely on signatures — parameter types, a return type that's the same or a covariant subtype, no new checked exceptions the base didn't declare — because those are the only facts about a method that exist as static, inspectable metadata in the class file before the method ever runs. Behavior — what the method actually does when it runs — isn't a fact the compiler has access to at all; it can see that save(Order) returns Order and throws nothing new, but it cannot see that the body unconditionally throws UnsupportedOperationException, because reading a method body for behavioral intent is not what a signature check does or can do. invokevirtual (the bytecode instruction behind a normal method call) doesn't encode which method body to run at compile time at all — it encodes a signature to look up, at run time, against whatever the object's actual class turns out to be, via that class's method table. The lookup happens after the object exists, using its real class, which is precisely why the override's real behavior — including a violation like an unexpected throw — is invisible until that lookup happens and the wrong body runs.

The lesson behind it →
Previous`@Transactional void placeOrder(Order o) { save(o); notify(o); }` calls `private void notify(Order o) { ... }` on the same class, and `notify` is also annotated `@Transactional(propagation = REQUIRES_NEW)` — the intent being "notify commits in its own transaction, independent of placeOrder's." It doesn't. Why not, precisely, and would making `notify` public fix it?Next A cache is built as `Map<Order, InvoiceDraft> pendingInvoices = new HashMap<>();`, keyed by the `Order` aggregate itself, with `equals`/`hashCode` overridden to include `status` because "two orders are only really the same if they're in the same state." Orders go into the cache while `OPEN`, and `pendingInvoices.get(order)` starts returning `null` for orders that are definitely still in the map. Walk through exactly what happens, bucket by bucket.
More on SOLID
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?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?