Code10x
Inheritancehard5-8 years

`class InstrumentedSet<E> extends HashSet<E> { int added = 0; @Override public boolean add(E e) { added++; return super.add(e); } @Override public boolean addAll(Collection<? extends E> c) { added += c.size(); return super.addAll(c); } }` — calling `addAll(List.of("a", "b", "c"))` on a fresh instance leaves `added == 6`, not 3. Where do the extra three come from, and what does it say about extending a class you don't own?

HashSet.addAll is inherited from AbstractCollection, and its implementation happens to work by calling add() once for each element in the given collection — an internal detail of how addAll gets its job done, not part of its documented contract. Because add() is overridden in InstrumentedSet, and every call to it — including the ones addAll's own implementation makes internally — is a virtual call that dispatches to whichever add() the actual object's class provides, each of those three internal calls lands on InstrumentedSet's overridden add(), incrementing added three more times on top of the three addAll itself already added. The count for three elements ends up at six: three from addAll's own += c.size(), three more from add() firing three times underneath it. The lesson this example is famous for (it's Effective Java's own): whether one inherited method calls another is an implementation detail of a class you don't own, it can change release to release with no compile error and no test failure that only checks 'was a request timed/counted', and it's the concrete reason composition — wrapping a Set and forwarding to it explicitly — is usually the safer choice over extending one.

The lesson behind it →
PreviousA reporting service declares `private static final SimpleDateFormat FMT = new SimpleDateFormat("yyyy-MM-dd HH:mm")` and reuses it across every request. It passes every test. Under 200 concurrent requests in production, about one row in a thousand carries a date from a *different* request, and occasionally a `NumberFormatException` comes out of `parse`. What's actually happening, and why is `static` — not `SimpleDateFormat` alone — the other half of the bug?Next A `Plugin` interface adds `default boolean healthy() { return true; }`. A month later, one plugin author reports their health check is being ignored — the platform always treats their plugin as healthy regardless of what their code does. Their class extends a shared `BasePlugin`, which happens to already declare a public `boolean healthy()` method, unrelated to the interface, returning whether the plugin's background thread is alive. No compiler ever mentioned a conflict. Why not, and what actually happens at the call site?
More on Inheritance
`class Base { Base() { init(); } void init() {} }` and `class Derived extends Base { final List<String> items = new ArrayList<>(); @Override void init() { items.add("x"); } }` — constructing a `Derived` throws `NullPointerException` inside `init()`, on a field marked `final` that's initialised right there at its declaration. How, precisely, does an object's class pointer already being `Derived` from the moment of allocation explain this, and why doesn't `final` help?