Java Inheritance: How the extends Keyword Works and When to Avoid It

A one-line change to a shared base class — adding an audit log call, tightening a validation check — ships clean through code review and breaks forty tests overnight. Nobody touched those tests. Java inheritance is what connects them: every subclass silently depends on exactly how its parent behaves, and that dependency is invisible until a change ripples through it. Java inheritance lets a subclass reuse and extend a parent class’s fields and methods, using the extends keyword — simple syntax hiding a real architectural risk. This guide covers how inheritance actually works, why deep hierarchies become fragile, and when composition is the better call.

What Is Java Inheritance?

Inheritance lets one class acquire the fields and methods of another, expressing an “is-a” relationship — a CreditCardTransaction is a Transaction, a ChromeDriver is a WebDriver. Java supports only single inheritance for classes: a class can extend exactly one parent, though it can implement multiple interfaces. Not everything from the parent transfers automatically.

Single Inheritance and Why Java Skips the Diamond Problem

Languages that allow a class to extend multiple parents run into the diamond problem: if two parent classes both define a method with the same signature, which one does the subclass inherit? Oracle’s official Java inheritance documentation confirms Java sidesteps this entirely by restricting classes to single inheritance. Multiple behaviors still come from multiple sources through interfaces, which can each define default methods — but a class implementing two interfaces with conflicting default methods is forced to resolve the conflict explicitly, rather than leaving it to silent, ambiguous resolution.

The Fragile Base Class Problem

The fragile base class problem is a well-documented risk in object-oriented design: a change to a base class that looks completely safe in isolation can break subclasses that depended on the base class’s exact prior behavior, not just its documented contract. The base class author has no way to see every subclass that exists, and the subclass author has no way to know which of the base class’s behaviors their code is silently relying on.

BaseTransactionProcessor
one small change here

CreditCardProcessor

ACHProcessor

WireTransferProcessor

All three subclasses inherit the change automatically
even the ones whose tests never touched the modified code path

Where This Shows Up in QA, BA, and IT Work

Page Object Base Class Changes Breaking Dozens of Tests

Selenium frameworks commonly build a base Page Object class with shared wait logic, navigation helpers, and element interaction methods, with every page-specific class extending it. A single change to that base class’s wait timing or element-finding logic can ripple through every subclass simultaneously — the exact scenario covered in the defect below.

Legacy Entity Class Hierarchies

Healthcare and financial systems built over many years frequently accumulate deep inheritance chains in their data model — a Person base class extended by Patient, extended by InpatientRecord, extended further still. Each additional layer makes the fragile base class problem worse, since a change at the top of the chain now has to be traced through every intermediate layer to understand its full blast radius.

Test Data Builder Inheritance Chains

Test data builders sometimes inherit from each other to share setup logic — a BaseClaimBuilder extended by DeniedClaimBuilder, extended by AppealedClaimBuilder. This works until a change meant for one specific scenario in the base builder silently alters test data for every builder further down the chain.

Composition vs. Inheritance: The Real Decision

Joshua Bloch’s Effective Java — widely regarded as one of the field’s standard references — famously argues for favoring composition over inheritance except when a genuine, stable “is-a” relationship exists. Composition means a class holds a reference to another class and delegates to it, rather than extending it directly.

The test worth applying before reaching for extends: can you honestly say the subclass is a more specific version of the parent, or are you just trying to reuse some convenient methods? The first case is inheritance. The second is composition wearing the wrong syntax.

class BasePage {
    void waitForLoad() { /* generic wait logic */ }
}
class DashboardPage extends BasePage {
    @Override
    void waitForLoad() { /* custom timing, ignores parent entirely */ }
}

class WaitHelper {
    void waitForElement(WebElement el, Duration timeout) { /* shared logic */ }
}
class DashboardPage {
    private final WaitHelper waits = new WaitHelper();
    void waitForLoad() { waits.waitForElement(loadingSpinner, Duration.ofSeconds(15)); }
}

Common Mistakes and Edge Cases

Using inheritance purely for code reuse. If the only reason a class extends another is to avoid retyping a few methods, and no genuine is-a relationship exists, that’s the composition-over-inheritance test failing — and it’s usually a sign the shared logic belongs in a standalone helper class instead.

Deep inheritance chains, four levels or more. Every additional layer multiplies the number of places a behavior could originate from, making a defect harder to trace back to its actual source. A method call three levels up an unfamiliar hierarchy is a common reason code review takes longer than it should.

Overriding without understanding base class invariants. As the financial scenario shows, a base class can have implicit assumptions — about call order, about what state exists by the time a method runs — that were never written down anywhere, and an override that doesn’t honor them can compile perfectly while still breaking.

Exposing protected fields across a hierarchy. protected fields are directly accessible to every subclass, which feels convenient until five subclasses are all reading and writing the same field with different assumptions about its current state — a well-known erosion of encapsulation that composition avoids by default.

When I’d Use Inheritance vs. Composition

Inheritance: when the is-a relationship is genuinely stable and unlikely to change — a browser driver implementing a standard interface, a specific exception type extending a general one. Selenium’s WebDriver hierarchy, covered in more depth in this site’s polymorphism and extensibility guide, is a well-behaved example.

Composition: the default choice whenever you’re reusing behavior without a true is-a relationship, or when the shared logic is likely to need different variations across the classes that use it. It costs a little more boilerplate upfront and saves considerably more debugging time later.

Quick Reference Checklist by Role

The next time one small change to a shared class breaks features that never should have been connected, don’t just fix the immediate symptom. Check whether that class is being extended for a genuine is-a relationship or just borrowed for convenience — and if it’s the latter, that ripple effect will happen again until the inheritance becomes composition.

Further reading: Oracle’s official Java inheritance tutorial covers the full language specification. For interface-based design as a composition-friendly alternative, see Oracle’s official interfaces tutorial.