Inheritance-for-Reuse Critique

## The third thing inheritance gives you When a class extends another it acquires three separable things. First, the base's **public API**, which becomes part of the derived type — this is what the classic reuse critique is about (a stack built by extending a random-access list is also indexable in the middle). Second, the base's **method bodies**, the code reuse people say they wanted. Third, and least discussed, **direct access to the base's data**: the fields the base declares `protected` in Java, C++, C# or Kotlin, or in some languages every field it has. Every composition mechanism replaces the first two. None of them replaces the third. A wrapper object holding a `Base` can call `Base`'s public methods; it cannot see `Base`'s private fields, and no amount of forwarding invents that access. That asymmetry is why "just use composition" is cheap advice on a whiteboard and expensive in a codebase. ## `protected` is a second public API A published `protected` field has an audience you cannot enumerate: every subclass anyone ever writes. It therefore obeys the same versioning rules as a public member — you can widen it, never narrow it, never remove it, never change its type or meaning. `java.util.Vector` declares `elementData`, `elementCount` and (via `AbstractList`) `modCount` as protected. That decision permanently fixed the representation: Vector can never become a chunked or paged structure, because external subclasses index `elementData` directly. `Stack extends Vector` inherits both the polluted public API and this frozen representation. Worse, a mutable protected field means the base can no longer maintain its own invariants. Anything a subclass can write, the base must treat as untrusted — but base methods don't re-validate, so the honest statement is that the invariant simply isn't enforced. `protected` doesn't just leak the representation; it hands out write access to it. Two details people get wrong. In Java, `protected` also implies package access, so it is *wider* than "subclasses only". In C++, a derived class may only reach a protected non-static member through an object of its own type — `Base& b; b.protectedField;` inside `Derived` is ill-formed, while `Derived& d; d.protectedField;` is fine. Kotlin's `protected` is narrower than Java's: subclasses only, no package rule. ## Five languages, five answers about shared state **Smalltalk** takes the choice away. Instance variables are visible to `self` and to every subclass, always; there is no way to declare one private to the defining class. (Symmetrically, no object can touch *another* object's instance variables at all, not even one of the same class — unlike Java's per-class `private`.) So in Smalltalk every subclass is coupled to the superclass's representation by construction, and the discipline has to live in convention and accessor methods. **Java and C++** make it opt-in with `protected`, which is exactly the trap: it looks like a small local decision and is actually a permanent API commitment. **Scala traits** can declare concrete `val`s and `var`s, so a trait carries state. The cost is initialization order: trait fields are assigned in linearization order, so a trait constructed earlier that reads a field declared in a trait constructed later observes the type's default — `0`, `false`, `null` — with no warning. The Scala 2 workarounds are `lazy val`, turning the member into a `def`, or early definitions; Scala 3 replaced that machinery with trait parameters. Stateful mixins are possible, but the state has a construction-time hazard that plain fields in a class do not. **Rust traits cannot hold data at all.** A default method can only call other methods of the trait. Shared state is therefore reached through a *required accessor* the implementor supplies — commonly `fn inner(&self) -> &Shared` plus `fn inner_mut(&mut self) -> &mut Shared` — or by holding the struct as a field and writing forwarders, which is why delegation macro crates exist. The upside is that the state dependency is written down in the trait's signature; the downside is per-implementor boilerplate and borrow-checker friction when a default method needs two parts of the state mutably. **Go embedding** shares fields: an embedded struct's fields are promoted to the outer type, so the outer type reads and writes them directly. What it does not share is identity — a promoted method runs with the *embedded value* as receiver, so a base method calling another method never dispatches to an outer redefinition. You get inheritance's state coupling without inheritance's open recursion. ## What the alternatives actually cost Replace protected fields with protected accessor methods: representation freedom comes back and the setter can validate, but you still have a second API and still have a fragile base class. Extract the shared state into its own object that base and derived both hold: this genuinely converts inheritance into composition, but it is a change to the *base*, so it's unavailable to anyone who doesn't own it. And plain contain-and-delegate only works if everything the subclass touched is already public — if it read a protected field, the refactor requires widening the base's public API, the exact opposite of the encapsulation win you were chasing. C++ private inheritance and Eiffel's non-conforming inheritance drop the subtype claim but keep the data access, which is why they remain the pragmatic escape hatch. Deep hierarchies compound all of this: state introduced at depth 2 is readable and writable at depths 2 through 5, and no single class in the chain can state, let alone enforce, an invariant over it.