Theory
One button, two prices
At the canteen counter, a student taps their card: the till charges Rs 27 for the thali. A staff member taps the same reader, buying the same thali: Rs 24.
The cashier did not switch machines or open a different program. One action, bill(card), behaved differently depending on who tapped.
Your code can do this too, and the idea has a grand name: polymorphism, the fourth and final pillar of OOP.
Theory
One word, many performances
Say "namaste" to your grandmother, your professor, and your best friend. Same word, three different deliveries: tone, gesture, warmth all adapt to the receiver.
Polymorphism is exactly that in code: one name whose behaviour adapts to the object performing it. The caller says one thing; the receiver decides what that means for them.
Theory
Polymorphism, formally
Polymorphism comes from Greek: poly (many) + morphe (form): one name, many forms.
Definition for the exam: polymorphism is the ability of a single function name, operator or interface to behave differently in different contexts.
In C++ the "context" can be decided at two moments:
- while compiling (which version fits these arguments?),
- while running (which object is actually receiving this call?).
At a glance
The two families (details in the next lessons)
| Family | Decided | Achieved by |
|---|---|---|
| Compile-time (static) | During compilation | Function overloading, operator overloading |
| Run-time (dynamic) | While the program runs | Virtual functions + inheritance |
Theory
Both families at the counter
Compile-time flavour: the till has bill(double amount) and bill(double amount, double discount). Two functions, one name; the compiler picks by looking at the arguments you passed. Done before the program ever runs.
Run-time flavour: Student and Staff both inherit from Person and each defines its own discount(). The counter holds a Person reference; only when a real card taps does the program discover which discount() to run.
Same pillar, two mechanisms.
Quiz
The till defines bill(double amt) and bill(double amt, double disc). You call bill(50.0). When is it decided which version runs, and what is this called?
- At compile time; function overloading (compile-time polymorphism)
- At run time; virtual function dispatch
- At compile time; inheritance
- At run time; operator overloading
Show the answer
At compile time; function overloading (compile-time polymorphism)
The argument list (one double) already tells the compiler exactly which version matches, so the decision happens during compilation: this is function overloading, the compile-time family. Run-time dispatch (option B) only enters when virtual functions and base-class pointers are involved, and no inheritance appears in this scenario at all.
Think first
Spot the run-time case
A function is written once: void charge(Person &p) { total = total - p.discount(); }. Sometimes a Student is passed, sometimes a Staff. Before tapping: why can the compiler NOT decide which discount() runs, and what must the program do instead?
Show the answer
At compile time the parameter is just "some Person": the actual object (Student? Staff?) only exists when the program runs and a real card taps. So the decision must be postponed to run time, where the call is routed to the object's own discount(). C++ needs the function marked virtual for this routing to happen, which is exactly where the next lessons pick up.
Watch out
The classification trap
Exams ask: "Is function overloading run-time polymorphism?" No: overloading is resolved by the compiler, making it compile-time (also called static or early-bound) polymorphism.
And do not claim polymorphism always needs inheritance: the run-time family needs it, but overloading works in a single class with no parent in sight. Match the family to the mechanism, not to a blanket rule.
Theory
Why designers love it
The charge() function above will never change again: add a Guest card next year with its own discount(), and charge() serves it without one edit. Code open for extension, closed for modification: that is the professional payoff of polymorphism, and interviewers phrase it exactly that way.
Summary
Key takeaways
- Polymorphism = one name, many forms: the fourth OOP pillar.
- One call behaves differently by context: arguments passed or object receiving.
- Compile-time family: function and operator overloading, resolved by the compiler.
- Run-time family: virtual functions with inheritance, resolved as the program runs.
- Overloading is NOT run-time polymorphism: classic classification trap.
- New derived classes plug into old polymorphic code without editing it.
- Memory hook: namaste to grandmother, professor, friend.