Beyond extends: 5 Surprising Truths About Java Inheritance

 

Inheritance is one of a Java developer's first lessons. At its core, it's simple: a Child class can inherit fields and methods from a Parent class. This "is-a" relationship is fundamental to object-oriented programming, allowing us to build hierarchies and reuse code. We learn the extends keyword, and for many, the lesson stops there.

But beneath this straightforward definition lies a system of carefully considered rules, counter-intuitive behaviors, and design decisions with profound implications. These rules aren't arbitrary; they exist to ensure type safety, prevent logical contradictions, and enable powerful features like polymorphism.

This article moves beyond the textbook definition to explore some of the most impactful and non-obvious truths about how inheritance really works in Java. Understanding the "why" behind these rules will change how you design and write your code.

A Parent Reference Can't See a Child's Unique Methods—Even When It Holds a Child Object

One of the most flexible features of inheritance is the ability to use a parent class reference to hold a child class object. For example, Parent p1 = new Child(); is perfectly valid Java code. It seems intuitive that since p1 actually holds a Child object, you should be able to call any of the Child's methods. This is not the case.

The rule is that even when a parent reference holds a child object, you can only call methods defined in the parent class using that reference. The instructor in our source material calls this a "very dangerous point" precisely because it feels counter-intuitive. Trying to call a method that only exists in the child class will result in a compiler error, likely stating something like cannot find symbol: method M2() location: class Parent.

Consider this code example:

class Parent {
    public void M1() {
        System.out.println("parent");
    }
}

class Child extends Parent {
    public void M2() {
        System.out.println("child");
    }
}

class Test {
    public static void main(String[] args) {
        Parent p1 = new Child();
        p1.M1(); // Valid
        p1.M2(); // Invalid - Compiler Error!
    }
}

The call to p1.M1() is valid because M1() is defined in the Parent class. However, the call to p1.M2() is invalid because the compiler only sees p1 as a Parent type, and the Parent class has no M2() method.

parent reference can be used to hold child object but by using that reference we can call only the methods available in the parent class we can't call child specific methods

This principle is a cornerstone of Java's compile-time type checking. While it might seem restrictive, it is the key to enabling polymorphism, a powerful concept that allows a single interface to represent different underlying forms.

Code Reusability Isn't Just a Buzzword; It's the Blueprint of the Entire Java API

The primary advantage of inheritance is code reusability. By placing common methods in a parent class, multiple child classes can use them without having to rewrite the same logic, solving the problem of code redundancy. The impact is not trivial; it can dramatically reduce development time and complexity.

Imagine designing a loan module without inheritance. You might have separate classes for different loan types, creating significant code redundancy:

• VehicleLoan (300 methods)
• HomeLoan (300 methods)
• PersonalLoan (300 methods)

This approach requires writing a total of 900 methods and could take 90 hours of development time.

Now, consider the same module built with inheritance. You realize that 250 methods are common to all loan types. By placing these in a parent Loan class, the structure changes:

• Loan (250 common methods)
• VehicleLoan extends Loan (50 specific methods)
• HomeLoan extends Loan (50 specific methods)
• PersonalLoan extends Loan (50 specific methods)

This new approach requires writing only 400 methods and reduces development time to 40 hours. You write the common code once and reuse it everywhere.

This exact principle is the blueprint for the entire Java API. The Object class is the ultimate parent, or root, for all Java classes. It contains 11 common methods fundamental to any object. Because every class in Java is a child of Object, these 11 methods are automatically available to over 5,000 core Java classes without ever being rewritten.

This design pattern appears in other foundational areas of the API as well. The Throwable class, for instance, acts as the root for the entire Java exception hierarchy. The most common methods required by any exception or error are defined in Throwable, ensuring that this core functionality is available to every class in the hierarchy without being rewritten. This design provides a common, reliable foundation for every object and every throwable in the Java ecosystem.

Java Says "No" to Multiple Inheritance for a Very Good Reason: Ambiguity

A Java class can extend only one other class. An expression like Class A extends B, C is invalid and will cause a compiler error. Java's designers deliberately chose to forbid this kind of "multiple inheritance" for classes to prevent a critical issue: the ambiguity problem.

To understand this, imagine if a class could have two parents.

• Class C extends both Parent P1 and Parent P2.
• Parent P1 has a method called M1().
• Parent P2 also has a method with the exact same name, M1().

Now, if you create an object of Class C and call the M1() method, which version should be executed? The one from P1 or the one from P2? The compiler would have no way to resolve this conflict. This confusion is known as the ambiguity problem. To avoid it entirely, Java simply does not allow a class to extend more than one parent.

...But Interfaces Get a Special Pass to Break the Rule

In surprising contrast to classes, an interface can extend multiple other interfaces. This means interface C extends A, B is perfectly valid. This seems to contradict the rule against multiple inheritance, but it's allowed because the ambiguity problem doesn't apply to interfaces.

The reason is simple: interfaces contain only method declarations (signatures), not implementations (code bodies).

Even if a child interface inherits two M1() method declarations from two different parent interfaces, there is no conflict. The conflict only arises when there are two different implementations to choose from. In the case of interfaces, a single implementation class is responsible for providing the one, unique code body for that method.

even though multiple method declarations are available but implementation is unique and hence there is no chance of ambiguity problem in interfaces

Because the final implementation is singular, there is no ambiguity for the compiler to resolve, making multiple inheritance safe for interfaces.

Here's an expert secret, though: strictly speaking, what interfaces provide isn't true inheritance in the same sense as classes. Because only method signatures are passed down—not implementations—no actual code is being reused. However, because an interface can extend multiple other interfaces, it is commonly and practically referred to as a form of multiple inheritance.

Java Protects You From Creating "Inheritance Loops"

Java's inheritance model requires a clear, hierarchical, and acyclic structure. To enforce this, Java forbids "cyclic inheritance," which would create a logical impossibility.

The following scenarios are illegal and will produce a compiler error for cyclic inheritance involving A:

1. A class extending itself:
2. Two classes extending each other:

This is forbidden because, as the source material notes, it's a "useless" concept. If Class A needs all of B's methods and Class B needs all of A's methods, it implies that all the methods should simply be defined within a single, unified class. The prohibition of cyclic inheritance protects the logical integrity of the class hierarchy.

Conclusion: Beyond the Textbook Definition

Inheritance in Java is more than just a simple parent-child relationship for sharing code. It is a robust system governed by a set of well-defined rules that promote code reuse, guarantee type safety, and maintain logical consistency across the entire language. By understanding the reasons behind limitations like the ban on multiple inheritance for classes or the prevention of inheritance loops, we gain a deeper appreciation for the design of the language.

Now that you see the 'why' behind these rules, how does it change the way you think about designing your own class hierarchies?