Method Overriding in Subclasses

Imagine counting everyone in a school building. You could write separate logic for teachers, students, and administrators. Polymorphism offers another approach: treat each person as a SchoolMember while allowing each subtype to keep its specialized behavior. The code works with the shared parent type instead of needing to know every concrete subtype.

A subtype is a specialized form of its parent type. A Teacher object can therefore be used anywhere a SchoolMember is expected, and a Student object can be treated in the same general way. The code using the object does not need to care which specific subtype it received. It can rely on the behavior and functionality associated with the parent type.

This makes one piece of code reusable across multiple subtypes. Instead of creating separate functions for teachers and students, you can write one operation that works with SchoolMember objects. When a new subtype is added, that existing operation can continue working without modification.

Suppose SchoolMember provides a tell() method, and Teacher and Student each provide their own version. A variable can be treated as a SchoolMember reference while actually holding a Teacher object. When tell() is called, the Teacher version runs. If the object is a Student, the Student version runs instead.

This selection is dynamic dispatch. The method that executes is determined at runtime from the actual object type, not from the parent type used to refer to the object. The decision happens each time the method is called, so one collection of SchoolMember references can contain different subtypes and still invoke the correct implementation for each object.

The important design choice is that the processing logic depends on SchoolMember rather than on a list of concrete subtype checks. The objects are handled through the same parent-type view, but dynamic dispatch preserves the correct behavior for each actual object.

Inheritance works in the other direction when functionality is added to the parent. If a new ID card field is added to SchoolMember, both Teacher and Student objects automatically have access to it. The same propagation applies to new parent-class methods. Subtypes inherit the parent class's attributes and methods without requiring each subtype to be modified separately.

Changes made inside one subtype remain isolated. If a new method is added only to Teacher, that method does not appear in Student and does not modify SchoolMember. Likewise, changing how Teacher behaves does not change the behavior of Student or the parent class.

Polymorphism supports the Open-Closed Principle. Code using the parent type is open for extension because new subtypes can be added, but closed for modification because the existing code does not need to change for each new subtype. This design also improves maintainability: subtype-specific behavior can be changed in the subtype while the parent class and other subtypes remain unaffected.