10 Inheritance and Polymorphism

The inheritance relationship

Inheritance lets a new class reuse common state and behavior from an existing class while adding specialized capabilities. The existing class is the superclass, and the new class is the subclass.

In Java, the extends keyword declares this relationship. If Dog extends Animal, a Dog object can use accessible members defined by Animal and can also define behavior such as bark() that belongs specifically to dogs.

The relationship should express a genuine is-a connection: a dog is an animal, a bicycle is a vehicle, and a circle is a shape. A subclass should also be usable wherever the superclass is expected without violating the superclass's behavioral expectations.

Constructors are not inherited. A subclass constructor can initialize superclass state by calling super(...). The super keyword can also invoke an overridden superclass method when the subclass wants to preserve the original behavior and add to it.

Takeaway: Use inheritance to represent a meaningful specialization, not merely to reuse a few unrelated methods.

Changing inherited behavior

A subclass can change inherited instance behavior through Method overriding. The overriding method uses the same method name and a compatible parameter list as the inherited method.

For example, Animal might define makeSound(), while Dog and Cat each provide their own implementation. Writing @Override above the subclass method is recommended because the compiler can detect a mismatch instead of treating the method as an unrelated overload.

Overriding is different from overloading. Overriding replaces inherited behavior in a subclass. Overloading creates multiple methods with the same name but different parameter lists, usually within one class. Static methods are hidden rather than overridden with runtime dispatch.

A subclass can call super.makeSound() when it needs the original superclass behavior before adding specialized behavior. Be cautious about declaring fields with the same name as superclass fields: this creates separate fields and can make the resulting code difficult to understand.

Takeaway: Use @Override for intended instance-method replacement, and distinguish a changed implementation from a method with a different parameter list.

Polymorphism and runtime behavior

Polymorphism allows one general reference type to work with objects of multiple specialized types. For example, both Animal first = new Dog() and Animal second = new Cat() are valid because each object is compatible with the Animal type.

When code calls an overridden instance method through one of these references, Dynamic method dispatch selects the implementation belonging to the actual runtime object. Thus, first.makeSound() can produce the dog behavior while second.makeSound() produces the cat behavior, even though both references are declared as Animal.

This makes shared processing concise. A method that accepts an Animal can call makeSound() without testing whether the object is a dog, cat, or another subclass. The same principle works with arrays and other collections: a loop can invoke the common operation on every element while each object supplies its specialized implementation.

Takeaway: Program against a useful superclass contract or interface, and let overridden methods provide type-specific behavior.

General and specialized references

A subclass object can be assigned to a superclass reference through Upcasting. For example, an Animal reference may refer to a Dog object. This conversion is safe because every Dog is an Animal.

The reference determines which members are directly visible at compile time. If bark() exists only in Dog, an Animal reference cannot call it directly, even when it currently refers to a dog. The reference can call members declared by Animal, including methods that use dynamic dispatch.

Downcasting is the reverse operation: converting a superclass reference to a subtype reference so that subtype-specific members can be used. Check the object's actual type before casting, for example with instanceof. A cast is invalid when the object is not an instance of the target subtype and can cause ClassCastException at runtime.

Frequent casts and type tests often indicate that the superclass contract is missing an appropriate operation. Prefer polymorphic methods when the behavior can be expressed cleanly through the general type.

Takeaway: Upcast freely when the subtype satisfies the general contract; downcast only when the runtime type has been established and the subtype-specific operation is genuinely needed.

Abstract designs and composition

An Abstract class defines a common structure without representing a complete object that can be created directly. It may contain shared fields, implemented methods, and abstract methods that concrete subclasses must implement.

For example, an abstract Shape class can require an area() method. Circle then implements area() using the circle-specific formula, while another shape supplies its own formula. Code can still hold a Shape reference and call area() polymorphically.

An abstract class is useful when related types share state or implementation as well as a required set of operations. It provides more shared structure than a purely abstract contract while ensuring that each concrete subtype supplies the operations that depend on its specific representation.

Inheritance is not always the best design. Composition expresses a "has-a" relationship: a Car has an Engine, but a car is not an engine. The car can delegate start() to its engine without inheriting the engine's entire interface.

Prefer composition when the relationship is not genuinely "is-a," when reuse is the only motivation, or when a superclass would impose behavior that the proposed subclass might need to disable or contradict. Composition often reduces coupling and makes helper objects easier to replace.

Takeaway: Choose inheritance for a substitutable specialization with meaningful shared behavior; choose composition for contained parts, delegation, or more flexible reuse.