Fragile base class problem in Java inheritance

Direct Answer

The fragile base class problem occurs when a change that preserves a base class's ordinary public behavior breaks a subclass that relied on an overridable method, protected state, call order, or another extension detail. It is a risk of implementation inheritance, not proof that every parent refactor or every inheritance design will fail.

Code Example

class Bag {
    protected final List<String> values = new ArrayList<>();

    public void add(String value) { values.add(value); }

    // Version 1: bulk operation writes directly.
    public void addAll(List<String> input) { values.addAll(input); }
}

class CountingBag extends Bag {
    private int added;

    @Override public void add(String value) {
        added++;
        super.add(value);
    }

    @Override public void addAll(List<String> input) {
        added += input.size();
        super.addAll(input);
    }
}

If Bag.addAll is later refactored to for (String value : input) add(value);, normal Bag results are unchanged, but CountingBag.addAll counts once in its own override and again through the overridable add calls.

Common Mistakes & Pitfalls

• Using a non-breaking public signature as the only test: subclass extension behavior may still change.
• Showing a refactor that does not actually bypass or duplicate the override: trace dynamic dispatch step by step.
• Calling inheritance an encapsulation violation in every case: the issue is an undocumented or unstable extension surface.
• Prescribing 'fully abstract or final' as the only choices: documented template methods and stable abstract bases are also valid.
• Assuming composition removes all change risk: callers still depend on the collaborator contract.