Python Hierarchical Inheritance: Structure and Use

What Hierarchical Inheritance Looks Like in Python

Python hierarchical inheritance describes a class structure where a single base class is inherited by multiple derived classes. The result is a tree-shaped hierarchy: the base class sits at the root, and each derived class branches from it. A derived class can itself become the base for further subclasses, which keeps the entire hierarchy rooted at the same original class.

class Vehicle:
    def __init__(self, make, model):
        self.make = make
        self.model = model

    def start(self):
        return f"{self.make} {self.model} is starting"


class Car(Vehicle):
    def start(self):
        return f"{self.make} {self.model} engine is running"


class Motorcycle(Vehicle):
    def start(self):
        return f"{self.make} {self.model} engine is revving"

Here Car and Motorcycle both inherit from Vehicle. Both reuse the __init__ logic from Vehicle, but each overrides start() to provide its own behavior. That is the defining characteristic of hierarchical inheritance: a single base class fans out into multiple specialized subclasses.

How Method Resolution Works in a Hierarchy

When you call a method on an instance of Car or Motorcycle, Python looks up the method using the class's MRO (method resolution order). For a simple hierarchy like the one above, the MRO is straightforward: the derived class first, then the base class, then object.

print(Car.__mro__)

This prints:

(<class '__main__.Car'>, <class '__main__.Vehicle'>, <class 'object'>)

The MRO matters when a derived class does not override a method. If Car did not define start(), calling start() on a Car instance would fall through to Vehicle.start(). That is how shared behavior is reused across all branches of the hierarchy.

For deeper hierarchies, Python computes the MRO using the C3 linearization algorithm. Because hierarchical inheritance avoids multiple parents by definition, C3 produces a predictable order: the derived class, then its ancestors in depth-first order. Multiple inheritance complicates this, but hierarchical inheritance does not introduce that complication.

A Practical Example: Modeling a Payment System

Consider a payment processing domain. A single Payment base class can define the common contract, while each payment method implements its own processing logic.

class Payment:
    def __init__(self, amount):
        self.amount = amount

    def process(self):
        raise NotImplementedError


class CreditCardPayment(Payment):
    def process(self):
        return f"Charging {self.amount} to credit card"


class BankTransferPayment(Payment):
    def process(self):
        return f"Initiating bank transfer of {self.amount}"


class PayPalPayment(Payment):
    def process(self):
        return f"Processing {self.amount} via PayPal"

Each subclass inherits the amount attribute from Payment and provides its own process() implementation. Code that accepts a Payment instance can call process() without knowing which concrete payment method it is dealing with. That is the practical value of hierarchical inheritance: a common interface with polymorphic behavior.

Common Mistakes When Building Hierarchies

One frequent mistake is placing too much behavior in the base class. If Payment contained logic specific to credit cards, the other subclasses would inherit behavior that does not apply to them. The base class should contain only what is genuinely common to every subclass.

Another mistake is overriding __init__ without calling the base class initializer. If CreditCardPayment defines its own __init__ to add a card_number field, it must call super().__init__(amount); otherwise the amount attribute is never set.

class CreditCardPayment(Payment):
    def __init__(self, amount, card_number):
        super().__init__(amount)
        self.card_number = card_number

A third issue is deep hierarchies. A hierarchy that grows several levels deep becomes harder to trace because behavior can be spread across many classes. If you find yourself overriding methods in nearly every subclass, the base class may be too abstract, and the hierarchy may be forcing behavior that should be composed rather than inherited.

When Hierarchical Inheritance Is the Right Choice

Hierarchical inheritance is appropriate when the subclasses genuinely share a common interface and common state. In the payment example, every payment method has an amount and a process() method. That shared contract justifies a common base class.

It is less appropriate when subclasses share only a name but not behavior. If two classes have nothing in common except that they both happen to be called entities, forcing them under a single base class adds coupling without value. Composition or a plain protocol is usually the better fit.

A useful decision rule: if you can describe the relationship as "is-a" for every subclass, hierarchical inheritance fits. If the relationship is "has-a" or "uses-a," composition is the better choice.

Maintainability and Runtime Considerations

The main maintainability risk in hierarchical inheritance is the base class becoming a dumping ground. Every method added to the base class is inherited by all subclasses, so additions should be reviewed carefully. A change to the base class affects every branch of the hierarchy, which can be both an advantage and a hazard.

At runtime, attribute and method lookup follows the MRO, which for hierarchical inheritance is a linear search through the class's ancestor chain. Shallow hierarchies have negligible lookup cost. Deep hierarchies with many levels can add measurable overhead, though in typical applications the impact is small compared to the cost of the method body itself.

The more important runtime concern is correctness, not speed. Because a method call can resolve to any class in the ancestry, a change in the base class can silently alter the behavior of all subclasses. Tests should exercise each concrete subclass directly, not only the base class, to catch regressions introduced by base-class changes.