The phrase "fragile base class" is used for two different failures — one about behaviour and one about compiled binaries. Distinguish them, say which platforms suffer which, and explain why the mitigations do not transfer between the two.

## Why one name covers two problems Both failures share a shape — a change to a base class breaks code that derives from it, without the deriving code changing — so both inherited the label. They are otherwise unrelated: one is about *meaning*, one is about *memory layout*, and knowing which one an author means is often the difference between understanding a design rule and cargo-culting it. ## Semantic fragility The behavioural problem comes from open recursion. Because a base's self-calls are dispatched on the runtime type, a subclass's overrides are woven into the base's internal control flow. When the base is refactored — one method reimplemented in terms of another, a helper hoisted, an operation now routed through a hook — the subclass's overrides are invoked in a new pattern. Nothing in a signature changed, so no compiler and no linker can notice. The subclass was depending on undeclared facts, and the base author never promised them. The mitigations are all about the contract. Either you write the self-use down and treat it as public API, so it cannot be refactored without a version bump; or you remove the extension point, exposing an explicit collaborator instead of an overridable method; or you close the hierarchy so the set of subclasses is known and testable. There is no automated remedy, and recompiling everything does not help, because the code compiles perfectly and computes the wrong answer. ## Binary fragility The binary problem comes from ahead-of-time compilation against a fixed layout. In C++, a derived class's compiled code needs to know where its own members sit in the object — which means it needs the base's size — and where each virtual function's entry sits in the virtual table, which is an index fixed at compile time. Both facts come from the header at the time the derived class was compiled. Ship a new version of the library with one extra `private` data member in the base, and every already-compiled derived class computes wrong offsets; add a virtual function anywhere but the end, and vtable indices shift. The failure is not a clean link error but memory corruption, which is why the mitigations are so heavy-handed. Those mitigations are all forms of hiding layout from the client. The **pimpl idiom** puts every data member in a forward-declared implementation struct, so the public class contains exactly one pointer and its size never changes. **Pure-abstract interfaces plus factory functions** ensure clients never derive from, or allocate, a concrete type. **Reserved padding** — spare bytes in the base for future members — is the blunt version used in some long-lived ABIs. Note that none of these makes a subclass more robust to a change of *behaviour*; they protect only against a change of *shape*. ## Who solved which Objective-C hit the binary form squarely and named it the fragile instance variable problem: a subclass in an application compiled its ivar offsets against the framework's base class, so Apple could not add storage to `NSView` and friends without breaking shipped software. The modern (64-bit) Objective-C runtime fixed it by computing ivar offsets at class-load time and having compiled code read them indirectly. Framework classes gained the freedom to evolve their storage, and the mitigation cost a level of indirection on ivar access. Java and the CLR were designed after the lesson. Class files and assemblies reference fields and methods symbolically; layout and virtual-slot assignment happen when the class is loaded and the code is JIT-compiled. Adding a private field to a base class, or a new method that does not clash, is binary-compatible: existing subclass binaries keep working without recompilation. What these platforms still have is a set of *source and link* compatibility rules with their own traps — a `static final` primitive or String constant is inlined into the caller's class file at compile time, so changing its value has no effect until callers are rebuilt; adding a method to a base whose signature a subclass already declares changes what that subclass method means, and can break the build outright if the return types are incompatible. ## Why the mitigations do not transfer The two problems fail at different times through different mechanisms. Binary fragility fails at load or at first access, deterministically, for a purely mechanical reason, and is therefore fixable by a purely mechanical technique — an extra indirection, whether inserted by the runtime (Objective-C, the JVM) or by the programmer (pimpl). Semantic fragility fails at whatever point the changed control flow reaches a subclass, is data-dependent, and is caused by a promise nobody wrote down. No indirection helps, because the code is calling exactly what it intended to call. Conversely, documenting your self-use patterns beautifully does nothing for a shifted vtable index. The practical takeaway for an architect: when someone proposes a rule justified by "fragile base class", ask which one. If the answer is layout, the correct response is an ABI strategy. If the answer is behaviour, the correct response is a contract strategy — and on a managed platform where the binary form does not exist, an ABI-flavoured mitigation such as pimpl is pure ceremony.