Python OOP — Inheritance, super(), and Method Overriding Explained

The Story That Explains Inheritance

Why We Need Inheritance — The DRY Argument

Suppose you're modelling three types of vehicles. Without inheritance, you'd write the same brand, wheels, speed, start() logic three times. Change something? Update three places. Add a fourth vehicle type? Copy-paste again. Bugs drift in. Behaviour diverges.

Basic Syntax

# ── Parent class (also called base class or superclass) ──
class Vehicle:
    def __init__(self, brand, wheels):
        self.brand  = brand
        self.wheels = wheels

    def start(self):
        print(f"{self.brand} engine starting...")

# ── Child class inherits by putting parent in parentheses ──
class Car(Vehicle):     # "Car IS-A Vehicle"
    pass                # nothing new yet — but it already has __init__ and start()

# ── Use the child — it inherits everything from the parent ──
my_car = Car("Honda", 4)   # uses Vehicle's __init__
my_car.start()                # uses Vehicle's start() → "Honda engine starting..."
print(my_car.brand)          # Honda
print(my_car.wheels)         # 4

Animated Diagram — The Inheritance Tree

Watch a three-level hierarchy come together: Vehicle at the top, Car in the middle, ElectricCar at the bottom. Each child inherits everything above it and adds its own. On the right, one tesla instance shows the full set of attributes it can reach — from every level of the chain.

Extending — Adding New Attributes and Methods to the Child

Inheriting is only half the story. The real power of a child class is to add its own attributes and methods without touching the parent. The child has everything the parent has, plus whatever new stuff you define.

class Vehicle:
    def __init__(self, brand, wheels):
        self.brand  = brand
        self.wheels = wheels
        self.speed  = 0

    def accelerate(self, amount):
        self.speed += amount
        print(f"{self.brand} now at {self.speed} km/h")


class Car(Vehicle):
    def __init__(self, brand, doors, fuel_type):
        # Call the parent's __init__ first — we'll cover super() next
        super().__init__(brand, wheels=4)
        # Now add child-specific instance variables
        self.doors     = doors
        self.fuel_type = fuel_type

    # A brand-new method that only Car has
    def open_doors(self):
        print(f"Opening all {self.doors} doors of the {self.brand}")


honda = Car("Honda Civic", doors=4, fuel_type="petrol")
honda.accelerate(50)         # inherited from Vehicle
honda.open_doors()            # brand-new on Car
print(honda.wheels)         # 4  (set by parent's __init__)
print(honda.fuel_type)      # petrol  (added by child)

Method Overriding — Replacing the Parent's Behaviour

Sometimes the parent's method isn't quite right for the child. An electric car doesn't start with a roar — it starts silently. Instead of adding a new method, the child redefines a method with the same name. This is called overriding.

class Car:
    def __init__(self, brand):
        self.brand = brand

    def start(self):
        print(f"{self.brand} engine starts with a ROAR!")


class ElectricCar(Car):
    # Same method name → this REPLACES the parent's start()
    def start(self):
        print(f"{self.brand} powers on silently. Ready to drive.")


petrol   = Car("Honda")
electric = ElectricCar("Tesla")

petrol.start()              # Honda engine starts with a ROAR!
electric.start()            # Tesla powers on silently. Ready to drive.

Animated Diagram — Method Resolution Order (Where Python Looks)

When you call tesla.accelerate(60), Python doesn't guess — it follows a strict rule: start at the object's own class, then walk up the chain. The first match wins. This is the Method Resolution Order (MRO).

super() — Reaching Back to the Parent

When you override a method but still want the parent's behaviour plus your own, use super(). It gives you a reference to the parent so you can call its version first, then add.

class Vehicle:
    def __init__(self, brand, wheels):
        self.brand  = brand
        self.wheels = wheels
        print(f"  [Vehicle] set brand={brand}, wheels={wheels}")

    def describe(self):
        return f"{self.brand} with {self.wheels} wheels"


class Car(Vehicle):
    def __init__(self, brand, doors):
        super().__init__(brand, wheels=4)   # call parent __init__ first
        self.doors = doors
        print(f"  [Car] added doors={doors}")

    def describe(self):
        # EXTEND the parent's describe() instead of replacing it entirely
        base = super().describe()
        return f"{base}, {self.doors} doors"


class ElectricCar(Car):
    def __init__(self, brand, doors, battery_kwh):
        super().__init__(brand, doors)            # chain up to Car → Vehicle
        self.battery_kwh = battery_kwh
        print(f"  [ElectricCar] added battery_kwh={battery_kwh}")

    def describe(self):
        base = super().describe()                # uses Car's describe → uses Vehicle's describe
        return f"{base}, {self.battery_kwh} kWh battery"


print("Creating Tesla...")
tesla = ElectricCar("Tesla Model 3", doors=4, battery_kwh=75)
print()
print(tesla.describe())

Animated Diagram — The super() Chain in Action

Watch what happens when ElectricCar("Tesla", 4, 75) runs. Each level's __init__ jumps up to its parent via super().__init__(...) — the chain climbs all the way to Vehicle, then unwinds back down, filling in one layer of attributes at each return.

Types of Inheritance

Complete Practical Example — Vehicle Hierarchy

A full three-level inheritance chain using everything from the tutorial: inheritance, extension, overriding, and super() chaining. Ready to paste and run.

class Vehicle:
    """Base class — everything on wheels shares this."""
    def __init__(self, brand, wheels):
        self.brand  = brand
        self.wheels = wheels
        self.speed  = 0

    def start(self):
        print(f"{self.brand} engine starts with a ROAR!")

    def accelerate(self, amount):
        self.speed += amount
        print(f"{self.brand} → {self.speed} km/h")

    def info(self):
        return f"{self.brand} · {self.wheels} wheels · {self.speed} km/h"


class Car(Vehicle):
    """A Car is a Vehicle with doors and a fuel type."""
    def __init__(self, brand, doors, fuel_type):
        super().__init__(brand, wheels=4)     # parent handles brand/wheels/speed
        self.doors     = doors
        self.fuel_type = fuel_type

    def open_doors(self):
        print(f"{self.brand}: opening {self.doors} doors")

    def info(self):
        # EXTEND parent info — don't rewrite it
        return super().info() + f" · {self.doors} doors · {self.fuel_type}"


class ElectricCar(Car):
    """An ElectricCar is a Car powered by a battery."""
    def __init__(self, brand, doors, battery_kwh):
        super().__init__(brand, doors, fuel_type="electric")
        self.battery_kwh  = battery_kwh
        self.charge_level = 100

    # OVERRIDE — electric cars start silently
    def start(self):
        print(f"{self.brand} powers on silently — battery at {self.charge_level}%")

    # New method only on ElectricCar
    def charge(self, amount):
        self.charge_level = min(100, self.charge_level + amount)
        print(f"{self.brand} charged to {self.charge_level}%")

    def info(self):
        return super().info() + f" · {self.battery_kwh} kWh · {self.charge_level}% charged"


# ── Create one of each ──────────────────────────────────────
honda = Car("Honda Civic", doors=4, fuel_type="petrol")
tesla = ElectricCar("Tesla Model 3", doors=4, battery_kwh=75)

# ── Start each — override behaviour is obvious ──────────────
honda.start()          # uses Vehicle.start()
tesla.start()          # uses ElectricCar.start() (override)

# ── Inherited methods work everywhere ───────────────────────
honda.accelerate(40)   # inherited from Vehicle
tesla.accelerate(80)   # inherited from Vehicle

# ── Level-specific methods ──────────────────────────────────
honda.open_doors()     # added in Car
tesla.charge(-10)      # added in ElectricCar (drops charge)

print()
print(honda.info())     # chained super().info() calls
print(tesla.info())     # chained super().info() calls, 3 levels deep

Practical Example 2 — Extending Auth: Developers Need an Extra OTP

A real-world pattern that shows the "extend, don't replace" principle in its cleanest form. Every Employee logs in with a username + password. But Developers need one extra step — an OTP (one-time password) — because they have access to production systems. The child class overrides auth() but reuses the parent's username/password check via super().auth(...) instead of rewriting it. Change the base auth logic later? Every subclass automatically inherits the fix.

class Employee:
    """Base auth for every employee — username + password only."""
    def __init__(self, username, password):
        self.username  = username
        self._password = password        # in real code: store a hash, not plaintext

    def auth(self, username, password):
        """Verify username + password. Returns True on success."""
        print(f"  [Employee.auth] checking username & password for {username!r}...")
        if username != self.username:
            print("    ✗ username mismatch")
            return False
        if password != self._password:
            print("    ✗ password mismatch")
            return False
        print("    ✓ base credentials OK")
        return True


class Developer(Employee):
    """Developers need everything the Employee needs — PLUS an OTP."""
    def __init__(self, username, password, otp_secret):
        super().__init__(username, password)     # let Employee handle username/password
        self._otp_secret = otp_secret            # developer-specific field

    # OVERRIDE — same method name, extra parameter (otp)
    def auth(self, username, password, otp):
        # Step 1 — DELEGATE the username/password check to the parent.
        #          If Employee.auth ever changes, we get the fix for free.
        if not super().auth(username, password):
            return False

        # Step 2 — the ADDITIONAL check that only developers need
        print(f"  [Developer.auth] checking OTP for {username!r}...")
        if otp != self._otp_secret:
            print("    ✗ OTP mismatch")
            return False
        print("    ✓ OTP verified")
        return True


# ── Regular employee: only username + password ──────────────
alice = Employee("alice", "MyPass123!")
print("Alice logs in:")
print("  → result:", alice.auth("alice", "MyPass123!"))
print()

# ── Developer: needs username + password + OTP ──────────────
bob = Developer("bob", "DevPass456!", otp_secret="774123")

print("Bob (dev) logs in with correct OTP:")
print("  → result:", bob.auth("bob", "DevPass456!", otp="774123"))
print()

print("Bob (dev) logs in with WRONG OTP — parent OK, child fails:")
print("  → result:", bob.auth("bob", "DevPass456!", otp="000000"))
print()

print("Bob (dev) logs in with WRONG password — parent short-circuits:")
print("  → result:", bob.auth("bob", "wrong", otp="774123"))

What Just Happened — Step by Step

isinstance() and issubclass() — Checking the Family

Once you have a hierarchy, you often want to ask: "Is this object one of the family?" Python gives you two built-in checks. Both understand inheritance — an ElectricCar counts as a Car and as a Vehicle.

tesla = ElectricCar("Tesla", 4, 75)

# ── isinstance(obj, ClassOrTuple) — is this object one of these types? ──
print(isinstance(tesla, ElectricCar))    # True — its own type
print(isinstance(tesla, Car))            # True — inherits from Car
print(isinstance(tesla, Vehicle))        # True — inherits from Vehicle
print(isinstance(tesla, object))         # True — everything is an object
print(isinstance(tesla, int))            # False — unrelated types

# ── issubclass(Cls, ParentOrTuple) — is Cls a subclass of Parent? ──
print(issubclass(ElectricCar, Car))       # True
print(issubclass(ElectricCar, Vehicle))   # True — walks the whole chain
print(issubclass(Car, ElectricCar))       # False — Car is not a subclass of its child

# ── Practical use — accept any Vehicle ─────────────────────
def describe_any_vehicle(v):
    if not isinstance(v, Vehicle):
        raise TypeError("Expected a Vehicle (or subclass)")
    return v.info()

print(describe_any_vehicle(tesla))         # works — Tesla is a Vehicle

Common Mistakes (and Fixes)

Quick Reference

Golden Rules