The one idea: many different kinds of things can be asked the same question ("what is your area?", "what sound do you make?"), and each kind answers in its own correct way — automatically , based on what it really is. Method overriding is simply the machinery that makes the right answer run without the caller ever checking which kind it is.
Before you can enjoy the parent topic , you need every word and symbol it leans on. This page builds each one from nothing, in the order that lets the next one make sense.
Everything below rests on these two words, so we earn them first.
A class is a blueprint — a description of what a kind of thing knows and can do. An object (also called an instance ) is a real thing built from that blueprint .
Think of a cookie cutter versus the cookies. The cutter is the class; each cookie you stamp out is an object.
Why the topic needs this: overriding is about classes redefining behavior, but which behavior runs is decided by the object . If you blur "class" and "object" together, the whole idea collapses. Keep them separate: blueprint vs built thing .
A method is an action a class can perform — a named block of code attached to a class. Writing obj.area() means "ask this object to run its area action."
The dot . is just plain English "'s": circle.area() = "the circle's area action, run it now". The parentheses () mean actually do it now (and hold any inputs).
A method's signature is its name plus the list of inputs it expects (their number and types). area() has signature "name area, no inputs". print(String s) has signature "name print, one text input".
Why the topic needs this: overriding demands the child use the same signature as the parent. If you can't yet see a signature as "name + inputs", you can't tell overriding (same signature) from overloading (same name, different inputs). This single distinction is half the topic.
Inheritance = a class (the child / subclass ) automatically gets all the methods of another class (the parent / superclass ), and may add or change some. We say the child is-a parent.
A Circle is-a Shape. So a Circle already owns everything a Shape promised, for free.
Why the topic needs this: overriding only happens inside an inheritance chain — the child re-defines a method the parent already gave it . No inheritance, no overriding. See Inheritance for the full build.
This is the trickiest pair, and the parent note's whole "which version runs?" question turns on it.
The declared type (a.k.a. static type ) is the type written next to a variable's name — what the compiler promises the variable holds. The runtime type (a.k.a. actual type ) is the type of the object the variable really points to right now .
In Shape s = new Circle();
declared type of s is Shape (the label on the box),
runtime type of the object is Circle (what's inside the box).
Why the topic needs this: the parent's central claim is "the runtime type chooses the method, the declared type only checks the call compiles." If these two words feel identical to you, that sentence is meaningless. Look at the figure: the label and the contents can differ — and behavior follows the contents.
"They're always the same, so why two words?"
Why it feels right: in Circle c = new Circle(); they are the same.
Fix: the moment a parent-typed variable holds a child object (Shape s = new Circle();), they split — and that split is exactly where overriding shows its power.
The parent note writes:
vtable ( C ) = { m ↦ most-derived definition of m visible in C }
Let's decode every glyph.
C — stands for "some class" (a placeholder letter, like x in algebra).
m — stands for "some method name" (e.g. area).
The arrow ↦ (read "maps to" ) means "this on the left is paired with this on the right." So m ↦ code means "the name area is paired with the actual code to run."
The braces { … } hold a table (a set of such pairings).
vtable ( C ) — the virtual method table of class C : its personal lookup sheet of "name → code".
Read the whole line as plain English: "class C 's lookup table pairs each method name with the newest (most-derived) version of that method visible from C ."
Why the topic needs this: the computer does not guess which area to run. It looks the object's real class up in this table. The child's table is a copy of the parent's with overridden rows rewritten . That single rewrite is what "override" physically means inside the machine.
The parent illustrates with shapes, so two tiny math symbols sneak in:
π r 2 — the area of a circle: π ≈ 3.14159 (a fixed number), r = the circle's radius, and r 2 = r × r . The little 2 means "multiplied by itself once."
w × h — the area of a rectangle: width w times height h . The × is ordinary multiplication.
Why the topic needs this: these are just two different recipes for the same word area. That "same word, different recipe" is the emotional core of overriding — the math itself is trivial; the point is that Circle and Rectangle disagree on how .
The Open/Closed Principle — code should be open to extension (add new behavior) but closed to modification (don't edit working code). Overriding lets you add a new subclass instead of editing an if/else. See Open-Closed Principle .
The Liskov Substitution Principle — anywhere a parent object is expected, a child object must work without surprises . An override must keep the parent's promise. See Liskov Substitution Principle .
Why the topic needs this: these two are the reason overriding is considered good design , not just a mechanism. They also explain the rules on what an override may and may not tighten.
declared type vs runtime type
vtable lookup name to code
method overriding dynamic dispatch
Read it bottom-up: overriding needs the vtable, which needs both a signature (the row name) and the runtime type (which table). Those in turn need the class/object split and inheritance. The two principles hang off the side as why we bother .
You are now equipped to read the parent's "HOW it works — derive dynamic dispatch" section without any symbol being new. Related siblings once you're comfortable: Polymorphism , Method overloading , Abstract classes and interfaces , super keyword .
Cover the right side; can you answer each before revealing?
A class is a ___ and an object is a ___ A class is a blueprint ; an object is a real thing built from it (an instance).
A method's signature is made of ___ Its name plus the list/type of inputs it expects.
The . in obj.area() means ___ and () means ___ . means "this object's"; () means "run it now (with these inputs)".
"Child is-a parent" describes which relationship? Inheritance — the child gets all the parent's methods for free.
In Shape s = new Circle();, the declared type is ___ and the runtime type is ___ Declared: Shape (the box label); runtime: Circle (what's inside).
Which type decides which overridden method actually runs? The runtime (actual) type of the object.
The symbol ↦ is read as ___ "maps to" — it pairs a name on the left with a value/code on the right.
vtable ( R ) [ m ] means ___Look up method name m in the lookup table of the object's runtime class R .
A child's vtable is built by ___ Copying the parent's table, then overwriting the rows it overrides.
The Open/Closed Principle says code should be ___ to extension and ___ to modification Open to extension, closed to modification.