Method overriding — when and why: Worked examples

This page is one big practice arena. The parent note built the idea of overriding (same signature, real object wins, chosen at runtime). Here we hit every kind of situation overriding can throw at you — the clean cases and the traps. Before each example, you forecast the answer, then we grind through it.

The scenario matrix

Every row is a "case class" this topic can produce. Each worked example below is tagged with the cell it covers, and every example carries its own figure.

#	Case class	What makes it tricky	Example
A	Pure specialize	child totally replaces parent body	Ex 1
B	Extend with `super`	child adds to parent body	Ex 2
C	Dispatch through base variable	declared type ≠ real type	Ex 3
D	Overload look-alike (NOT override)	different params → picked at compile time	Ex 4
E	Abstract contract (degenerate base)	parent body is empty/forbidden	Ex 5
F	Static "override" trap (hiding)	no dynamic dispatch happens	Ex 6
G	Liskov limit (narrowing = illegal)	override must stay substitutable	Ex 7
H	Real-world word problem	many shapes, one loop, zero `if/else`	Ex 8
I	Degenerate/limiting input	zero radius, empty list	Ex 9
J	Exam-style twist	mixed override + overload + `super` in one trace	Ex 10
K	Blocked override (`final` / `sealed`)	parent forbids overriding at all	Ex 11

Prerequisites you may want open: Inheritance, Polymorphism, Method overloading, Abstract classes and interfaces, Liskov Substitution Principle, Open-Closed Principle, super keyword. (These are cross-links to sibling notes in the same study vault — click one to review that concept if a word here feels new.)

Example 1 — Pure specialize (cell A) · 🟦 Python

Worked example

Statement. A Circle(r=2) and a Rectangle(3,4) both promise area(). Each child fully replaces the parent's area. What does the loop print?

import math
class Shape:
    def area(self): raise NotImplementedError
class Circle(Shape):
    def __init__(self, r): self.r = r
    def area(self): return math.pi * self.r ** 2   # OVERRIDE, replace
class Rectangle(Shape):
    def __init__(self, w, h): self.w, self.h = w, h
    def area(self): return self.w * self.h         # OVERRIDE, replace
for s in [Circle(2), Rectangle(3, 4)]:
    print(round(s.area(), 3))

Forecast: two numbers — one from pi * r^2, one from w * h. Guess them before reading on.

Picture it. The figure shows one for loop (blue) sending the same call s.area() into two different real objects. The orange arrow lands in Circle.area, the green arrow in Rectangle.area — same caller, two bodies.

Circle. Compute pi * r^2 = pi * 2^2 = 4*pi, i.e. $π r^{2} = 4 π$ . Why this step? The object is a real Circle, so dispatch lands in Circle.area, which ignores the parent body entirely.
Numerically 4*pi = 12.566... → rounded 12.566. Why this step? round(..,3) is just for a clean printable value.
Rectangle. Compute w * h = 3 * 4 = 12 → 12. Why this step? Same call s.area(), but the real object is Rectangle, so a different body runs. That's the whole magic — one caller, many bodies.

Verify: 4*pi ≈ 12.566 ✓, 3*4 = 12 ✓. Units: area is length², consistent for both.

Example 2 — Extend with `super` (cell B) · 🟦 Python

Worked example

Statement. SavingsAccount should describe itself as the parent does, plus extra text. Use super().

class Account:
    def describe(self): return "Account"
class SavingsAccount(Account):
    def describe(self):
        return super().describe() + " (Savings, 4% interest)"
print(SavingsAccount().describe())

Forecast: the child does NOT throw away "Account" — it builds on it. Guess the full string.

Picture it. The figure is a two-stage pipeline: the child override (orange) first reaches up via super() to run the parent body "Account" (blue), then appends its own text (green), producing the joined string.

Call child's describe. Real object is SavingsAccount, so its override runs. Why this step? Dispatch always starts at the real type.
super().describe() jumps to Account.describe, returning "Account". Why this step? super says "run the parent's version of this method deliberately" — reuse, don't re-type it.
Concatenate → "Account (Savings, 4% interest)". Why this step? Extend = parent's work plus child's addition.

Verify: result equals "Account (Savings, 4% interest)" ✓ — contains the parent's exact "Account" prefix, proving super actually ran the base body.

Example 3 — Dispatch through a base-typed variable (cell C) · 🟦 Python

Worked example

Statement. A variable is declared as the base Shape, but holds a Circle. Which area runs?

import math
class Shape:
    def area(self): return 0.0        # base default (not abstract this time)
class Circle(Shape):
    def __init__(self, r): self.r = r
    def area(self): return math.pi * self.r ** 2
s = Circle(5)                         # the variable holds a real Circle
print(round(s.area(), 4))

Forecast: does the base default (→ 0.0) win, or the real Circle (→ pi * 25) win?

Picture it. The figure draws the MRO as a search chain starting at the real class Circle. The thick red arrow follows the chain and stops at the very first match (Circle.area) — it never reaches the grayed-out Shape.area further down. The green box is the result pi * 25.

Find the real class. type(s) is Circle. Why this step? Lookup always begins at the object's actual class, never at any "declared" annotation.
Walk the MRO Circle → Shape → object and take the first area → Circle.area. Why this step? The child defines its own area, so the search matches immediately and stops; Shape.area is shadowed.
Run pi * 5^2 = 25*pi = 78.5398..., i.e. $25 π \approx 78.5398$ .

Verify: 25*pi ≈ 78.5398 ✓, not 0.0. The base default is never reached because the MRO finds the child's area first.

Example 4 — Overload look-alike, NOT override (cell D) · 🟧 Java-style

Worked example

Statement. Printer has two render methods (different signatures — see the definition up top); a child overrides one of them. Trace which body runs.

class Printer {
    String render(String s) { return "str:" + s; }
    String render(int n)    { return "int:" + n; }   // OVERLOAD (diff params)
}
class Fancy extends Printer {
    @Override
    String render(String s) { return "FANCY:" + s; }  // OVERRIDE (same signature)
}
Printer p = new Fancy();
p.render("x");   // ?
p.render(7);     // ?

Forecast: which line uses runtime dispatch, which uses compile-time selection?

Picture it. The figure splits each call into two stages: compile time (blue) picks which slot by argument type — String vs int; runtime (orange) picks which body fills that slot by the real object. Only the String slot has a child override, so only that call changes.

p.render("x"). Argument is String, so at compile time the render(String) slot is chosen (overload resolution by argument type). At runtime the object is Fancy, whose override fills that slot → "FANCY:x". Why this step? Overloading picks the slot by argument type (compile time); overriding decides which body fills that slot (runtime). Both mechanisms act — one after the other.
p.render(7). Argument is int, so the render(int) slot is chosen. Fancy never overrode that signature → parent body → "int:7". Why this step? No child override exists for that signature, so the inherited Printer.render(int) runs.

Verify: results "FANCY:x" and "int:7" ✓. Same word render, two totally different resolution mechanisms.

Example 5 — Abstract contract, degenerate base body (cell E) · 🟦 Python

Worked example

Statement. The base method is forbidden to call directly. Every child must override. What happens if we try the base version?

from abc import ABC, abstractmethod
class Shape(ABC):
    @abstractmethod
    def area(self):
        raise NotImplementedError   # explicit "no body yet" — never meant to run
class Square(Shape):
    def __init__(self, a): self.a = a
    def area(self): return self.a ** 2
print(Square(6).area())
# Shape()  # would raise TypeError: cannot instantiate abstract class

Forecast: Square(6).area() = ? And can you even build a bare Shape()?

Picture it. The figure shows the abstract base as a box with a hole (dashed, no body). A red "✗ cannot instantiate" arrow bounces off Shape; the green path goes to Square, which fills the hole and returns 36.

Square(6).area() runs the child override: 6^2 = 36. Why this step? The contract forces a body, so dispatch always finds a real implementation.
Shape() would fail at construction. Why this step? An abstract base with an unfilled abstractmethod is a degenerate type — it has a hole. Python refuses to make one, guaranteeing no caller ever hits an empty area.

Verify: 6^2 = 36 ✓. The degenerate base can never be instantiated, so the "empty body" case is unreachable — exactly the safety abstract classes give you.

Example 6 — Static "override" trap = hiding (cell F) · 🟧 Java-style

Worked example

Statement. A static method is redeclared in a child. Is it overridden (runtime) or hidden (compile time)?

class Base  { static String who() { return "Base"; } }
class Sub extends Base { static String who() { return "Sub"; } }
Base b = new Sub();
Base.who();   // ?
Sub.who();    // ?
b.who();      // ? (the "dangerous form" — calling a static via an instance)

Forecast: for b.who(), does the real object Sub win like normal overriding — or does the declared type Base win?

Picture it. The figure contrasts two resolution paths: a normal instance method (orange) follows the real object to Sub; a static method (gray) ignores the object entirely and resolves by the declared type Base. The b.who() call is drawn taking the gray path, ending on "Base" — the surprise.

Base.who() → "Base"; Sub.who() → "Sub". Why this step? Called on the class name — no object, no dispatch, purely the named class.
b.who() → "Base", not "Sub". Why this step? Statics use hiding: resolution is by the declared type of b (which is Base) at compile time. There is no vtable slot for a static, so the real object is ignored.

Verify: outputs "Base", "Sub", "Base" ✓. The surprise is the third — proof that statics are hidden, not overridden.

Example 7 — Liskov limit: narrowing is illegal (cell G) · 🟧 Java-style (Java 5+)

Worked example

Statement. Parent returns a Bird; a child wants to narrow the return to a Sparrow (a subtype). Legal? Then a child tries to narrow access from public to private. Legal? First we must define the classes so the snippet actually compiles:

// Define the type hierarchy the example relies on:
class Bird    { }
class Sparrow extends Bird { }        // Sparrow IS-A Bird
 
class Aviary { public Bird get()    { return new Bird(); } }
class SparrowHouse extends Aviary {
    @Override public Sparrow get() { return new Sparrow(); }  // covariant return — OK (Java 5+)
}
// class Bad extends Aviary {  private Bird get() {...}  }     // ILLEGAL: narrows access

Forecast: which of the two changes keeps substitutability?

Picture it. The figure ranks access by reachable audience on a number-line (private → protected → public). A green arrow points "widen (allowed)" toward public; a red arrow points "narrow (illegal)" toward private. Alongside, a small tree shows Sparrow under Bird, marked ✓ covariant.

Covariant return Sparrow. A Sparrow is a Bird, so any caller expecting a Bird from get() still gets a valid Bird. Why this step? Returning a subtype only ever gives callers more than promised — never less. Substitutability holds. This is the one legal tightening.
Narrowing access public → private. A caller of Aviary.get() could no longer call it on a Bad object. Why this step? That removes an ability the parent promised, so Bad is not a drop-in replacement. The compiler rejects it.

Verify: covariant return compiles (Sparrow is-a Bird → callers still satisfied); access-narrowing rejected. Direction rule as booleans: "widen allowed" = True, "narrow allowed" = False.

Example 8 — Word problem: billing many shapes, zero `if/else` (cell H) · 🟦 Python

Worked example

Statement. A tiling company charges $5 per square metre. Given a mixed list [Circle(1), Rectangle(2,3), Square(2)], compute the total bill using one loop and no type checks.

import math
class Shape:
    def area(self): raise NotImplementedError
class Circle(Shape):
    def __init__(self, r): self.r = r
    def area(self): return math.pi*self.r**2
class Rectangle(Shape):
    def __init__(self, w, h): self.w, self.h = w, h
    def area(self): return self.w*self.h
class Square(Shape):
    def __init__(self, a): self.a = a
    def area(self): return self.a**2
shapes = [Circle(1), Rectangle(2,3), Square(2)]
total_area = sum(s.area() for s in shapes)
bill = 5 * total_area
print(round(total_area, 4), round(bill, 4))

Forecast: add the three areas, multiply by 5. Estimate the bill first.

Picture it. The figure is a conveyor belt: three different shapes ride into one area() call, each dispatching to its own body, and their numbers drop into a single running sum (green), then scale by $5. No if/else diamond appears anywhere.

Circle(1): pi * 1^2 = pi = 3.1416. Why this step? Dispatch → Circle.area.
Rectangle(2,3): 2 * 3 = 6. Square(2): 2^2 = 4. Why this step? Each element dispatches to its own body — the loop never asks "what type is this?".
Total area: pi + 6 + 4 = 10 + pi = 13.1416.
Bill: 5 * (10 + pi) = 50 + 5*pi = 65.708. Why this step? This is Open/Closed in action — a new shape is a new class, and this billing loop never changes.

Verify: total area = 10 + pi ≈ 13.1416 ✓, bill = 50 + 5*pi ≈ 65.708 ✓. Units: m² × $/m² = $ ✓.

Example 9 — Degenerate / limiting inputs (cell I) · 🟦 Python

Worked example

Statement. Two edge cases: (a) a Circle(0) — zero radius; (b) an empty list of shapes fed to the billing sum.

import math
print(math.pi * 0**2)                    # zero radius
print(sum(s.area() for s in []))         # empty list

Forecast: what is the area of a zero-radius circle, and the total of no shapes?

Picture it. The figure shows a circle shrinking to a single point as r → 0 (its area label falling to 0), and beside it an empty box feeding into sum, whose output stays pinned at the starting value 0.

Circle(0): pi * 0^2 = 0. Why this step? Overriding doesn't change arithmetic — a degenerate circle collapses to a point, area 0. No special-case code needed.
Empty list: sum(...) of nothing = 0. Why this step? sum starts from a starting value (its identity element) of 0 and then adds each item to it. With zero items, nothing is added, so it simply returns that starting 0. That is why it does not crash and does not return None — the empty case is defined to give the additive identity 0, so the polymorphic loop degrades gracefully.

Verify: area = 0 ✓, empty total = 0 ✓. Both limiting inputs are safe — no NotImplementedError, no divide-by-zero.

Example 10 — Exam twist: override + overload + `super` in one trace (cell J) · 🟦 Python

Worked example

Statement. Trace the exact output. B overrides greet() and calls super(); it also gives tag a second parameter so one method handles two call shapes (Python's stand-in for overloading).

class A:
    def greet(self): return "A"
    def tag(self): return "tagA"
class B(A):
    def greet(self):                       # OVERRIDE (same signature as A.greet)
        return super().greet() + "B"       # deliberately runs the parent body first
    def tag(self, x=None):                 # replaces A.tag; default arg fakes overloading
        return "tagB" if x is None else f"tagB:{x}"
b = B()
print(b.greet())        # ?
a = B()                 # a genuine B, viewed through the A interface
print(a.greet())        # ?
print(b.tag())          # ?
print(b.tag(9))         # ?

Forecast: four lines. Watch the "real object always wins" rule on the second one.

Picture it. The figure is a trace table: each of the four calls is a row, with a small arrow showing where dispatch lands (B.greet, B.greet, B.tag, B.tag) and the produced string in a green cell. The super() hop inside greet is drawn as a dashed arrow up to A.greet.

b.greet(). Real object is B, so its override runs. Inside it, super().greet() returns "A", then + "B" gives "AB". Why this step? Override runs (dispatch on real object) and super deliberately pulls the parent body — both mechanisms in a single line.
a.greet() where a is another B → still "AB". Why this step? Runtime object decides, exactly like Example 3. Even if you think of a through the base A interface, dispatch uses the real B.
b.tag() → x defaults to None → returns "tagB". Why this step? Python has no compile-time overloading; the one tag uses its default parameter to cover the "no argument" call shape.
b.tag(9) → x = 9 (not None) → returns "tagB:9". Why this step? Same single method, different argument path — the if/else on x does the work a second overloaded method would do in Java.

Verify: outputs "AB", "AB", "tagB", "tagB:9" ✓.

Example 11 — Blocked override: `final` / `sealed` (cell K) · 🟧 Java / C#

Worked example

Statement. The parent forbids overriding a method. What happens when a child tries anyway?

// Java
class Ledger {
    final int checksum() { return 42; }     // 'final' = cannot be overridden
}
class HackedLedger extends Ledger {
    int checksum() { return 0; }             // COMPILE ERROR: cannot override final
}

// C# (modern): a virtual method may be 'sealed' in a subclass to stop further overriding
class Ledger        { public virtual int Checksum() => 42; }
class SafeLedger : Ledger { public sealed override int Checksum() => 42; }
class Evil : SafeLedger   { public override int Checksum() => 0; }  // COMPILE ERROR: sealed

Forecast: does the child's checksum ever run, or does the code even compile?

Picture it. The figure draws a "locked door": Ledger.checksum has a padlock icon; the child's attempted override (red) bounces off the padlock with a "✗ compile error" label, while the legal value 42 sits safely inside.

Java final. The compiler rejects HackedLedger.checksum() outright. Why this step? final on a method is a hard promise: "this body is the only body, forever." No override slot is ever reserved for a child version, so there is nothing to override. The program does not build.
C# sealed override. SafeLedger overrode Checksum once, then sealed it — closing the door for its own subclasses. Evil.Checksum() fails to compile. Why this step? sealed lets a class stop the override chain at itself: the method stays polymorphic up to SafeLedger, but Evil is blocked.

Verify: neither snippet compiles; the correct, expected checksum value is 42 in the legal (un-overridden) classes, never 0.

Recall

Runtime type of the object decides which override runs ::: Yes — the declared/static type only controls whether the call compiles (in typed languages). A method's signature is ::: its name plus the number/order/types of its parameters (return type usually excluded). How does Python find which area to run? ::: It walks the object's class MRO (e.g. Circle → Shape → object) and takes the first match — not a fixed vtable. A zero-radius circle's overridden area() ::: 0 (no special case needed). Static method redeclared in a child ::: Hidden, resolved by declared type at compile time — not overridden. Calling a static via an instance (b.who()) is dangerous because ::: it compiles but resolves by declared type, hiding behaviour and misleading readers. super().greet() inside an override ::: Deliberately runs the parent's body, then the child adds to it. When did Java allow covariant return types, and who enforces them? ::: Java 5+; the compiler checks the child's return is a subtype of the parent's. Legal way to "tighten" an override's return type ::: Return a subtype (covariant return) — never narrow access. Overriding a final (Java) / sealed (C#) method ::: Impossible — it is a compile-time error; the parent forbids it to protect an invariant. Why sum([]) returns 0 and not None ::: sum starts from the additive identity 0 and adds nothing, so it returns that 0.