Redefining Inherited Methods - Method Overriding | OneNoughtOne

0/246

System Design (HLD)Method Overriding

Method Overriding

LevelIntermediate

Duration60 mins

TopicMethod Overriding

1 / 4

Redefining Inherited Methods

The Power of Specialization

Inheritance gives subclasses access to the attributes and methods of their parent classes. But what happens when a subclass needs a method to behave differently than the version it inherited? This is where method overriding becomes essential—one of the most powerful mechanisms in object-oriented programming that enables specialization while maintaining polymorphic behavior.

Method overriding allows a subclass to provide its own specific implementation of a method that is already defined in its parent class. Rather than being forced to accept inherited behavior as-is, subclasses can redefine methods to suit their specialized needs while still conforming to the interface established by the parent.

What You Will Learn

By the end of this page, you will understand what method overriding is, why it is fundamental to polymorphism, how it differs from method hiding, and when overriding is the appropriate design choice. You'll see how overriding enables specialized behavior within a consistent inheritance hierarchy.

The Concept of Method Overrinding

Method overriding occurs when a subclass declares a method with the same signature (name, parameters, and in most languages, compatible return type) as a method in its parent class. When this happens, the subclass's version of the method replaces the parent's version for instances of that subclass.

Consider a simple example: a Shape class with a draw() method. Every subclass—Circle, Rectangle, Triangle—needs a draw() method, but each must draw something entirely different. The parent class defines the interface (the promise that all shapes can be drawn), while each subclass provides its own implementation (the specific drawing logic).

shape_hierarchy.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
class Shape:
    """Base class defining the shape interface."""
    
    def draw(self):
        """Draw the shape. Subclasses must override this."""
        print("Drawing a generic shape")
    
    def get_area(self):
        """Calculate area. Subclasses should override."""
        return 0
 
 
class Circle(Shape):
    """Circle specialization of Shape."""
    
    def __init__(self, radius):
        self.radius = radius
    
    def draw(self):
        """Override: Draw a circle specifically."""
        print(f"Drawing a circle with radius {self.radius}")
    
    def get_area(self):
        """Override: Calculate circle area."""
        import math
        return math.pi * self.radius ** 2
 
 
class Rectangle(Shape):
    """Rectangle specialization of Shape."""
    
    def __init__(self, width, height):
        self.width = width
        self.height = height
    
    def draw(self):
        """Override: Draw a rectangle specifically."""
        print(f"Drawing a {self.width}x{self.height} rectangle")
    
    def get_area(self):
        """Override: Calculate rectangle area."""
        return self.width * self.height
 
 
# Polymorphism in action
shapes = [Circle(5), Rectangle(4, 6), Shape()]
 
for shape in shapes:
    shape.draw()  # Each calls its own overridden version
    print(f"Area: {shape.get_area()}")

In this example, Circle and Rectangle both override the draw() and get_area() methods from Shape. When we iterate over a collection of shapes and call draw(), each shape executes its own version—the Circle draws a circle, the Rectangle draws a rectangle. This is runtime polymorphism in action: the same method call produces different behavior depending on the actual type of the object.

Why Override Methods?

Method overriding serves several critical purposes in object-oriented design, each addressing a fundamental need in building flexible, maintainable software systems:

Core Purposes of Method Overriding

•Specialization of Behavior — Subclasses represent specialized versions of their parent. A SavingsAccount calculates interest differently than a CheckingAccount, even though both are BankAccount types. Overriding enables each to implement its own interest calculation while sharing the common account interface.
•Polymorphic Substitution — Client code can work with the parent type while actual behavior comes from the specific subclass. This is the Liskov Substitution Principle in practice: a SavingsAccount can be used anywhere a BankAccount is expected, and it will behave appropriately.
•Extension and Enhancement — Subclasses can extend parent behavior rather than completely replacing it. An overriding method might call the parent's version and then add additional logic—a pattern we'll explore in detail when discussing super.
•Template Method Enablement — Abstract parent classes can define algorithmic skeletons where specific steps are overridden by subclasses. This powerful pattern separates invariant logic from variant implementations.
•Contract Fulfillment — When parent classes define abstract methods, subclasses must override them to provide concrete implementations, ensuring that all instances of the type hierarchy fulfill the expected contract.

The Single Point of Change Benefit

Method overriding promotes maintainability through localized changes. If Circle's drawing logic needs to change, you modify only Circle.draw(). Client code using Shape references doesn't need to know or care—it continues calling draw() and gets the updated behavior automatically.

Overriding vs Overloading: A Critical Distinction

One of the most common sources of confusion for developers learning OOP is the distinction between method overriding and method overloading. These terms sound similar but represent fundamentally different concepts:

Method Overriding: A subclass provides a new implementation for a method with the exact same signature that exists in the parent class. This is resolved at runtime based on the actual object type.

Method Overloading: Multiple methods in the same class (or a subclass) share the same name but have different parameter lists. This is resolved at compile time based on the method signature.

Overriding vs Overloading Comparison
Aspect	Overriding	Overloading
Definition	Replacing parent method implementation	Multiple methods with same name, different parameters
Inheritance	Requires inheritance (parent-child)	Same class or inheritance hierarchy
Method Signature	Must be identical (or covariant return)	Must differ in parameter types or count
Resolution Time	Runtime (dynamic dispatch)	Compile time (static binding)
Polymorphism Type	Runtime polymorphism	Compile-time polymorphism
Access Modifiers	Cannot be more restrictive	Can have any access modifier
Return Type	Same or covariant (more specific)	Can be different (not part of signature)
Purpose	Specialization of behavior	Convenience for different parameter types

overriding_vs_overloading.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
class Calculator {
    // Method OVERLOADING: same name, different parameters
    public int add(int a, int b) {
        return a + b;
    }
    
    public double add(double a, double b) {
        return a + b;
    }
    
    public int add(int a, int b, int c) {
        return a + b + c;
    }
}
 
 
class ScientificCalculator extends Calculator {
    // Method OVERRIDING: same signature as parent's add(int, int)
    @Override
    public int add(int a, int b) {
        System.out.println("ScientificCalculator adding...");
        return super.add(a, b);  // Can still use parent's implementation
    }
    
    // This is OVERLOADING in the subclass, not overriding
    public double add(double a, double b, double c) {
        return a + b + c;
    }
}
 
 
public class Demo {
    public static void main(String[] args) {
        Calculator calc = new ScientificCalculator();
        
        // Overriding: resolved at runtime, uses ScientificCalculator's version
        int result1 = calc.add(5, 3);  // Prints "ScientificCalculator adding..."
        
        // Overloading: resolved at compile time based on argument types
        double result2 = calc.add(5.0, 3.0);  // Uses Calculator's double version
        
        System.out.println(result1);  // 8
        System.out.println(result2);  // 8.0
    }
}

Common Mistake: Accidental Overloading

A frequent bug occurs when developers intend to override a method but accidentally change the parameter types, creating an overload instead. The parent's method continues to be called when expected to be overridden. In Java, using the @Override annotation catches this at compile time. In Python, tools like mypy can detect signature mismatches.

Overriding vs Method Hiding (Static Methods)

Another important distinction is between method overriding and method hiding. Method overriding applies to instance methods—methods that operate on object instances. But what happens with static methods in a class hierarchy?

Static methods belong to the class itself, not to instances. When a subclass defines a static method with the same signature as a static method in its parent, this is called method hiding, not overriding. The crucial difference lies in how the method is resolved:

Method Overriding (Instance Methods)

•Resolution based on runtime object type
•Calling parent.method() on a child object invokes child's version
•True polymorphic behavior
•Uses dynamic dispatch (virtual method table)
•The @Override annotation applies

Method Hiding (Static Methods)

•Resolution based on compile-time reference type
•Calling Parent.method() always uses Parent's version
•No polymorphic behavior
•Uses static binding (resolved at compile time)
•The @Override annotation does NOT apply

overriding_vs_hiding.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class Animal {
    // Instance method - can be overridden
    public void speak() {
        System.out.println("Animal makes a sound");
    }
    
    // Static method - can only be hidden, not overridden
    public static void describe() {
        System.out.println("I am an Animal");
    }
}
 
 
class Dog extends Animal {
    // OVERRIDES the instance method
    @Override
    public void speak() {
        System.out.println("Dog barks");
    }
    
    // HIDES the static method (NOT overriding!)
    public static void describe() {
        System.out.println("I am a Dog");
    }
}
 
 
public class Demo {
    public static void main(String[] args) {
        Animal animal = new Dog();  // Reference is Animal, object is Dog
        
        // Instance method: OVERRIDING - uses runtime type (Dog)
        animal.speak();  // Output: "Dog barks"
        
        // Static method: HIDING - uses compile-time reference type (Animal)
        animal.describe();  // Output: "I am an Animal"  <-- Not "I am a Dog"!
        
        // To get Dog's static version, must use Dog reference
        Dog.describe();  // Output: "I am a Dog"
    }
}

Design Implication

Method hiding is generally considered a code smell because it breaks the intuitive expectation of polymorphic behavior. If you need different static behavior per subclass, consider whether the method should be an instance method instead, or whether a different design approach (like factory methods) would be clearer.

The Mechanics of Overriding

Understanding how method overriding works at a mechanical level helps clarify why it behaves as it does. When you call an instance method on an object, the runtime system performs a process called dynamic dispatch (or late binding):

Identify the runtime type — Determine the actual class of the object (not the reference type)
Search the method table — Look up the method in that class's virtual method table (vtable)
Execute the found method — If the method exists in the subclass, use it; otherwise, traverse up the hierarchy

This process happens transparently every time you call a method on an object reference, enabling polymorphic behavior.

dispatch_mechanics.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
class Vehicle:
    def start(self):
        print("Vehicle starting...")
    
    def move(self):
        print("Vehicle moving in some way")
    
    def stop(self):
        print("Vehicle stopping...")
 
 
class Car(Vehicle):
    def move(self):
        # Override: Car has specific movement
        print("Car driving on wheels")
 
 
class Boat(Vehicle):
    def move(self):
        # Override: Boat has specific movement
        print("Boat sailing on water")
 
 
class Hovercraft(Vehicle):
    def move(self):
        # Override: Hovercraft has specific movement
        print("Hovercraft gliding on air cushion")
 
 
def travel(vehicle: Vehicle):
    """
    This function works with any Vehicle.
    The actual move() behavior depends on the runtime type.
    This is the power of method overriding + polymorphism.
    """
    vehicle.start()   # Uses Vehicle.start() (not overridden)
    vehicle.move()    # Uses the OVERRIDDEN version for each type
    vehicle.stop()    # Uses Vehicle.stop() (not overridden)
 
 
# Same code, different behaviors
travel(Car())        # "Car driving on wheels"
travel(Boat())       # "Boat sailing on water"
travel(Hovercraft()) # "Hovercraft gliding on air cushion"

In this example, the travel() function doesn't know or care about the specific type of vehicle it receives. It calls move(), and the runtime system ensures the correct overridden version executes. This decoupling—where client code depends only on the parent type but gets specialized behavior—is a cornerstone of extensible software design.

When Should You Override a Method?

Method overriding is a powerful tool, but like all tools, it should be applied thoughtfully. Here are guidelines for when overriding is appropriate:

Override When...

•The subclass represents a true specialization — A PremiumUser needs different discount logic than RegularUser, but both are User types
•The parent's implementation doesn't apply — A ReadOnlyFile should override write() to refuse writes, while maintaining file interface compatibility
•You need to extend behavior — Override to add logging, validation, or pre/post-processing while still leveraging the parent's core logic
•The method is designed for overriding — Methods marked virtual, abstract, or documented as extension points are meant to be overridden
•Behavioral contracts require it — Abstract methods must be overridden; failing to do so is a compile error in most languages

Don't Override When...

•The method is marked as final/sealed — The parent has deliberately prevented overriding for safety
•Overriding would violate the Liskov Substitution Principle — If your override makes the subclass unsuitable where the parent is expected, the design is flawed
•Composition would be cleaner — If you're overriding just to inject different behavior, consider composition with strategy objects instead
•The hierarchy relationship is incorrect — Needing to override most methods suggests inheritance wasn't the right relationship
•You're duplicating rather than specializing — If the override copies most of the parent's code with minor tweaks, refactor to use super or extract common logic

The Litmus Test

Ask yourself: 'Does my subclass represent a genuine specialization that should behave differently in this specific way?' If yes, override. If you're using overriding to work around a poor inheritance design, reconsider the class hierarchy itself.

Summary: Redefining Inherited Methods

We've established the foundational understanding of method overriding—one of the most powerful mechanisms in object-oriented programming. Let's consolidate the key concepts:

Key Takeaways

•Method overriding allows subclasses to replace inherited method implementations with specialized versions
•Overriding enables runtime polymorphism — the same method call produces different behavior based on the actual object type
•Overriding differs from overloading — overloading involves same-name methods with different parameters; overriding involves same-signature methods in a parent-child hierarchy
•Overriding differs from method hiding — static methods can only be hidden, not overridden, because they lack polymorphic dispatch
•Dynamic dispatch (virtual method tables) is the mechanism that makes overriding work at runtime
•Override when you genuinely need specialized behavior for a subclass, not just to tweak inherited code

What's next:

Now that we understand what method overriding is and why it matters, the next page explores the rules and constraints that govern overriding. Not just any method can be overridden, and not in any way—understanding these rules is essential for writing correct, maintainable inheritance hierarchies.

Page Complete

You now understand the concept of method overriding, its relationship to polymorphism, and how it differs from overloading and method hiding. Next, we'll examine the specific rules that control when and how methods can be overridden.