Java Superclass Subclass Basics and Casting

When a Java class extends another class, the original class becomes the superclass and the new class becomes the subclass. The subclass inherits the non-private fields and methods of the superclass, and it can override methods to change behavior. Understanding the java superclass subclass relationship is essential for designing object hierarchies that behave predictably and remain maintainable.

Declaring a Superclass and a Subclass

A subclass is declared with the extends keyword. The superclass can be a concrete class, an abstract class, or even another subclass in a longer chain. Here is a minimal example:

public class Animal {
    public void speak() {
        System.out.println("Animal speaks");
    }
}

public class Dog extends Animal {
    @Override
    public void speak() {
        System.out.println("Dog barks");
    }
}

The Dog class inherits the speak() method but overrides it. The @Override annotation is not required, but it causes a compile-time error if the method signature does not actually match a superclass method, which helps catch mistakes early.

How Method Overriding Affects Runtime Behavior

When you call a method on an object, Java uses the actual runtime type of the object to determine which implementation runs, not the declared type of the reference. This is dynamic dispatch. Consider:

Animal pet = new Dog();
pet.speak(); // prints "Dog barks"

The reference is of type Animal, but the object is a Dog. The JVM resolves speak() to the Dog override. This behavior is the foundation of polymorphism.

Constructors are different: they are not inherited. A subclass must call a superclass constructor, either explicitly with super(...) or implicitly. If the superclass has a no-argument constructor, the compiler adds super() automatically. If the superclass only defines a constructor with parameters, the subclass must call it explicitly. This is a common source of compile errors for developers new to inheritance.

Using the Super Keyword Inside a Subclass

The super keyword lets a subclass access the superclass's overridden methods, fields, or constructors. It is useful when the subclass extends the behavior rather than replacing it entirely.

public class Puppy extends Dog {
    @Override
    public void speak() {
        super.speak();
        System.out.println("Puppy whines");
    }
}

Here, super.speak() invokes the Dog implementation, which itself calls the Animal implementation? Actually no, Dog.speak() does not call super.speak(), so only the Dog implementation runs, then the Puppy adds its own line. This pattern lets you build on the parent behavior rather than duplicating logic. Using super correctly reduces code duplication and makes the hierarchy easier to maintain.

Upcasting and Downcasting

Assigning a subclass object to a superclass reference is called upcasting. It is always safe and happens implicitly.

Animal animal = new Dog(); // upcast

Upcasting narrows the accessible interface: you can only call methods declared in Animal, even though the actual object is a Dog. This is intentional; it enforces the contract defined by the superclass. Upcasting is common when you want to treat objects uniformly, such as storing different subclasses in a single collection.

Downcasting is the reverse: casting a superclass reference to a subclass type. It is not automatically safe because the runtime object may not be an instance of the target subclass. Downcasting requires an explicit cast and a runtime type check.

if (animal instanceof Dog) {
    Dog dog = (Dog) animal;
    dog.fetch(); // method only on Dog
}

The instanceof check prevents ClassCastException. In Java 16 and later, you can use pattern matching for instanceof to simplify this:

if (animal instanceof Dog dog) {
    dog.fetch();
}

Pattern matching avoids the separate cast and reduces boilerplate, but the underlying type check still happens at runtime.

Why Upcasting Is Preferable in Public APIs

Designing methods to accept superclass types rather than specific subclasses makes your code more flexible and easier to evolve. For example, a method that processes any Animal does not need to change when you add new subclasses, as long as they respect the Animal contract.

public void makeNoise(Animal animal) {
    animal.speak();
}

You can pass a Dog, a Puppy, or any future subclass. This reduces coupling and improves maintainability. If the method required a Dog, you would have to rewrite it or overload it for each new subclass. Following the Liskov substitution principle ensures that subclasses can replace their superclass without breaking behavior.

Common Pitfalls with Downcasting

A frequent mistake is assuming a superclass reference always holds a specific subclass. For example:

Animal animal = new Animal();
Dog dog = (Dog) animal; // ClassCastException at runtime

The cast compiles because Animal is a supertype of Dog, but the JVM throws ClassCastException because the actual object is not a Dog. This is why you should always verify with instanceof before downcasting, or design the code to avoid downcasting altogether.

Another subtle pitfall is overriding equals() or hashCode() in a subclass without respecting the superclass contract. If two objects are equal, they must have the same hash code. If a subclass adds fields that are not part of the equality check, that can lead to unexpected behavior when objects are stored in hash-based collections. But that is a more advanced concern; for the scope of this article, the main downcasting error is the ClassCastException.

Performance and Runtime Cost of Casting and instanceof

Using instanceof and casting does add a small runtime cost because the JVM must check the object's type. This cost is usually negligible compared to method calls or I/O, but in tight loops that process thousands of objects, excessive instanceof checks can add measurable overhead. If you find yourself downcasting frequently, consider whether the design could be improved—for example, by moving the varying behavior into a method on the superclass and letting subclasses override it.

The instanceof pattern matching introduced in Java 16 is compiled to the same type check, so it does not introduce additional overhead over the traditional cast. However, it improves readability and reduces the chance of casting the wrong type because the variable is only in scope if the check succeeds.

For most applications, the performance impact of type checks is negligible. The bigger concern is maintainability: repeated downcasting suggests that the design is not using polymorphism effectively. The JVM's JIT compiler can optimize common paths, but a clean object hierarchy is usually more valuable than micro-optimizing type checks.

Constructor Chaining and Initialization Order

When you create a subclass object, Java invokes the superclass constructor first, then the subclass constructor. This guarantees that the superclass state is initialized before the subclass uses it. Understanding this order is important when a subclass constructor relies on superclass fields.

public class Vehicle {
    protected int wheels;

    public Vehicle(int wheels) {
        this.wheels = wheels;
    }
}

public class Car extends Vehicle {
    public Car() {
        super(4); // must be the first statement
    }
}

If you forget to call super explicitly, the compiler will complain if the superclass has no no-argument constructor. This is a compile-time error, so it is easy to catch, but it illustrates why the constructor chain is strict.

Comparing Inheritance with Composition

Inheritance is a powerful tool, but it is not always the best choice. If a subclass overrides many methods or exposes a large surface area of the superclass, composition—holding a superclass instance as a field—might be more flexible. For example, a Dog class that contains an Animal object can delegate calls without being locked into the inheritance hierarchy. Composition avoids fragile coupling to superclass implementation details, but it requires more boilerplate if you need to expose many methods.

A useful rule is: use inheritance when the subclass truly is a subtype of the superclass, and when you want to benefit from polymorphism. Use composition when you want to reuse behavior without committing to the superclass's API.

When Inheritance Can Break Production Code

Inheritance has a subtle maintainability risk: if the superclass changes its implementation, subclasses may break even if their own code has not changed. For example, if a superclass method is modified to rely on a private field that a subclass overrides in a conflicting way, the behavior can become inconsistent. This is the fragile base class problem.

To mitigate it, keep superclass methods concise, document any contract that subclasses are expected to respect, and prefer overriding methods only when the superclass explicitly supports it. Also, avoid calling overridable methods from a superclass constructor—this can lead to a constructor invoking a subclass method before the subclass's fields are initialized, which causes surprising NullPointerExceptions.