4 Inheritance and Class Hierarchies

From General Types to Specialized Types

Inheritance lets a specialized class reuse and extend a more general class. The general class is the superclass, base class, or parent class; the specialized class is the subclass, derived class, or child class.

The central design test is the is-a relationship. If a Dog is an Animal, then Dog may inherit from Animal. A dog can use behavior such as eat() inherited from Animal and can add behavior such as fetch(). A hierarchy may continue through multiple levels, such as Animal to Mammal to Dog.

A subclass normally has one direct superclass in languages such as Java and C#, while a superclass can have many subclasses. Inherited members remain available through the hierarchy subject to access-control and language rules. Constructors are generally not inherited, although a subclass can invoke a superclass constructor.

Takeaway: Use inheritance to express a genuine specialization in which the child type can meaningfully be treated as the parent type.

Reusing Behavior and Defining Abstractions

A superclass can hold behavior shared by several related subclasses, allowing common code to be written once. For example, a Vehicle class might define start(), while an ElectricCar subclass reuses start() and adds chargeBattery().

This form of reuse is valuable when the shared behavior is genuinely common and stable. The superclass should not contain features that make sense for only one specialized type. Code reuse by itself is not enough to justify an inheritance relationship.

An abstract superclass is useful when the general concept is meaningful but should not be created directly. For example, an abstract Shape class can declare an area() operation, while a concrete Circle class supplies the implementation using its radius. The abstract class may contain shared implementation and can require each concrete subclass to provide essential operations.

Takeaway: Put stable, conceptually shared behavior in a superclass, and use abstraction when subclasses must complete a common contract.

Overriding and Run-Time Behavior

A subclass overrides an inherited method when it provides a new implementation with the same method signature. If Animal defines speak() and Dog overrides it, a dog can produce Bark instead of the general animal sound.

A subclass may also extend the original behavior. For example, LoudDog can call the superclass implementation through super.speak() and then add its own output. The corresponding keyword in C# is base.

Polymorphism appears when a variable uses a superclass type but refers to a subclass object. In the expression Animal animal = new Dog();, calling animal.speak() selects the overridden Dog.speak() implementation at run time. This lets a method or collection work with general Animal values while preserving specialized behavior.

Polymorphism is reliable when each subclass honors the behavior promised by the superclass. Similarly, code can request area() from every Shape without needing separate calling logic for each concrete shape.

Takeaway: Overriding supplies specialized behavior, while polymorphism lets general code select that behavior through a common type.

Choosing Inheritance or Composition

Inheritance creates dependencies between a superclass and all of its descendants. A change to inherited state, method behavior, construction, or access levels can affect many subclasses. Good design therefore requires more than a convenient way to copy code.

Use inheritance when:

• The subclass genuinely is a specialized version of the superclass.

• The superclass's public behavior makes sense for every subclass.

• Shared behavior is stable and belongs conceptually in the superclass.

• Every subclass can honor the expectations established by the superclass.

Avoid inheritance when:

• The relationship is really has-a or uses. A Car has an Engine; an Engine is not a kind of Car.

• A subclass would need to disable, ignore, or reject inherited operations.

• The superclass exposes implementation details that subclasses must depend on.

• Code reuse is the only reason for the relationship.

Composition is often preferable when one object contains or uses another. It can provide looser coupling and make independent behaviors easier to combine.

Takeaway: Choose inheritance for a stable conceptual relationship, not merely for implementation reuse.

Managing Hierarchy Risk

A deep inheritance hierarchy has many levels between a concrete class and its root. Such a structure can make important fields and methods difficult to locate, because behavior may be defined several levels above the class being inspected.

Deep hierarchies can also create fragile dependencies: a change near the top may alter many descendants. Several overrides of the same method can make execution order difficult to determine, and each level may impose requirements on construction and initialization. A subclass may also inherit operations that do not fit its meaning, weakening substitutability.

A shallow hierarchy with clear responsibilities is usually easier to understand, test, and maintain. When extension is not part of the design, languages can provide restrictions such as Java's final or C#'s sealed to prevent further inheritance of selected classes or methods.

Takeaway: Keep hierarchies shallow when possible, make responsibilities clear, and protect important invariants when subclasses should not extend a type.