System Design (LLD)Method Overriding (Revisited)

Method Overriding — The Engine of Runtime Polymorphism

LevelIntermediate

Duration55 mins

TopicMethod Overriding (Revisited)

3 / 4

Override Annotations

Declaring Intent, Preventing Errors

Method overriding is a powerful mechanism, but it's also error-prone. What happens if you think you're overriding a parent method but accidentally misspell it? What if the parent class changes its method signature and your override silently becomes a new, unrelated method? These silent failures can cause subtle, hard-to-diagnose bugs.

Override annotations are language features designed to make overriding explicit, visible, and verifiable. They transform overriding from an implicit relationship that might or might not exist into a declared contract that the compiler enforces.

What You Will Learn

By the end of this page, you'll understand the purpose and syntax of @Override in Java, the override keyword in C++, Python's conventions for documenting overrides, the specific errors that annotations prevent, and best practices for using override annotations in production code.

The Problem Override Annotations Solve

Before we look at annotation syntax, let's understand the real problems they address. Consider this scenario:

SilentFailure.java
Java (Problematic Code)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Original parent class
public class Document {
    public String render() {
        return content;
    }
}
 
// Developer thinks they're overriding render()
public class HtmlDocument extends Document {
    
    // PROBLEM: Typo in method name!
    // This is NOT an override—it's a new method
    public String reder() {  // Oops: 'reder' instead of 'render'
        return "<html>" + getContent() + "</html>";
    }
}
 
// Later in the code...
Document doc = new HtmlDocument("Hello");
String output = doc.render();  // Calls Document.render()!
// Developer expected HTML, got plain text
// No compilation error, no runtime error
// Just wrong behavior—the worst kind of bug

This code compiles and runs without any indication of a problem. The developer intended to override render(), but due to a typo, they created an entirely new method called reder(). The polymorphic call invokes the parent's render(), producing incorrect results.

Types of Override Errors:

Silent Override Failures

•Typos in method name — reder() vs render(), eqals() vs equals()
•Wrong parameter types — equals(String s) doesn't override equals(Object o)
•Extra or missing parameters — calculate(int a, int b) vs calculate(int a)
•Incompatible return type — overriding with a non-subtype return
•Parent method removal — parent class changes, child override becomes orphan
•Final method 'override' — trying to override a method marked final

All of these errors are silent without override annotations. The code compiles, often runs, but doesn't behave as intended. Override annotations make these errors into compile-time failures—exactly where we want to catch them.

@Override in Java

Java provides the @Override annotation as part of the standard library (java.lang.Override). When applied to a method, it tells the compiler: "I intend this method to override a superclass method. Please verify."

Syntax:

@Override
public ReturnType methodName(Parameters...) { }

What @Override Checks:

A method with the same name exists in a parent class or interface
The parameter types match exactly (proper overriding, not overloading)
The return type is compatible (same or covariant)
The parent method is not final
Visibility is not more restrictive

OverrideAnnotation.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
46
47
48
49
50
51
52
53
54
55
56
57
public class Document {
    private String content;
    
    public Document(String content) {
        this.content = content;
    }
    
    public String getContent() {
        return content;
    }
    
    public String render() {
        return content;
    }
    
    @Override
    public String toString() {
        return "Document[" + content + "]";
    }
    
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Document other = (Document) o;
        return Objects.equals(content, other.content);
    }
    
    @Override
    public int hashCode() {
        return Objects.hash(content);
    }
}
 
public class HtmlDocument extends Document {
    
    public HtmlDocument(String content) {
        super(content);
    }
    
    @Override  // <-- COMPILE ERROR if this doesn't actually override
    public String render() {
        return "<html><body>" + getContent() + "</body></html>";
    }
    
    // If we had a typo:
    // @Override
    // public String reder() {  // COMPILE ERROR: does not override
    //     return "";
    // }
    
    // If we had wrong parameters:
    // @Override
    // public boolean equals(String s) {  // COMPILE ERROR: no such method
    //     return false;
    // }
}

Best Practice: Always Use @Override

Use @Override on EVERY method intended to override a parent method—even if it seems obvious. This protects against future changes to parent classes, catches typos immediately, documents intent for readers, and enables IDE refactoring support. Most Java style guides mandate @Override usage.

@Override and Interfaces (Java 6+):

Originally, @Override only worked for superclass methods. Since Java 6, it also works for interface implementations. This is important because interface methods can change too:

InterfaceOverride.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
public interface Renderer {
    String render(Object content);
}
 
public class JsonRenderer implements Renderer {
    
    @Override  // Works since Java 6
    public String render(Object content) {
        // If the interface changed to render(String content),
        // this @Override would immediately cause a compile error
        return new Gson().toJson(content);
    }
}

override and final in C++

C++11 introduced the override and final keywords to address the same problems. Unlike Java where @Override is a metadata annotation, C++'s override is a contextual keyword with direct compiler significance.

C++ override Syntax:

virtual ReturnType methodName(Parameters...) override;

C++ final Syntax (prevent further overriding):

virtual ReturnType methodName(Parameters...) final;

OverrideKeyword.cpp
C++
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
51
52
53
54
#include <string>
 
class Document {
public:
    virtual ~Document() = default;
    
    virtual std::string render() const {
        return content_;
    }
    
    // Cannot be overridden by children
    virtual std::string getType() const final {
        return "Document";
    }
    
protected:
    std::string content_;
};
 
class HtmlDocument : public Document {
public:
    // CORRECT: explicitly declares override
    std::string render() const override {
        return "<html>" + content_ + "</html>";
    }
    
    // COMPILE ERROR: typo doesn't match any virtual method
    // std::string reder() const override { return ""; }
    
    // COMPILE ERROR: wrong const-ness doesn't match
    // std::string render() override { return ""; }  // Missing 'const'
    
    // COMPILE ERROR: getType() is final
    // std::string getType() const override { return "HTML"; }
};
 
class PdfDocument : public Document {
public:
    // override is optional but strongly recommended
    std::string render() const override {
        return "[PDF: " + content_ + "]";
    }
};
 
// Class marked final - cannot be inherited from
class SealedDocument final : public Document {
public:
    std::string render() const override {
        return content_;
    }
};
 
// COMPILE ERROR: cannot inherit from final class
// class ChildOfSealed : public SealedDocument {};

Key C++ Differences:

override is optional — Code compiles without it, but you lose safety checks
final prevents further overriding — The method cannot be overridden in subclasses
final on classes — The class cannot be inherited from at all
Signature matching is strict — const matters, reference qualifiers matter
Must be on virtual methods — Using override on non-virtual is an error

C++ Pitfall: Missing virtual

In C++, if you forget virtual in the parent class, override in the child will cause a compile error—but that's actually what you want! It catches the case where you thought a method was virtual but it wasn't. Always mark intended-to-be-virtual methods as virtual in base classes.

Override Indicators in Python

Python, being dynamically typed, doesn't have built-in override checking. Method dispatch is purely runtime, and there's no compile-time verification of override correctness.

However, Python developers have developed conventions and tools to achieve similar safety:

PythonOverrides.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
45
46
47
48
49
from abc import ABC, abstractmethod
from typing import override  # Python 3.12+
 
 
class Document(ABC):
    def __init__(self, content: str):
        self._content = content
    
    @property
    def content(self) -> str:
        return self._content
    
    @abstractmethod
    def render(self) -> str:
        """Render the document to a string format."""
        pass
 
 
class HtmlDocument(Document):
    
    # Python 3.12+ @override decorator
    # Type checker will error if this doesn't actually override
    @override
    def render(self) -> str:
        return f"<html><body>{self.content}</body></html>"
    
    # Prior to 3.12, use docstrings and type checkers:
    # def render(self) -> str:
    #     """Override Document.render to produce HTML."""
    #     return f"<html>{self.content}</html>"
 
 
# For Python < 3.12, use typing_extensions
from typing_extensions import override as override_ext
 
class PdfDocument(Document):
    
    @override_ext  # Works with mypy and pyright
    def render(self) -> str:
        return f"[PDF Document: {self.content}]"
 
 
# Third-party libraries like 'overrides' package:
# from overrides import overrides
#
# class MarkdownDocument(Document):
#     @overrides
#     def render(self) -> str:
#         return markdown.markdown(self.content)

Python's @override (3.12+):

Python 3.12 introduced the @override decorator in the typing module. It's a hint to type checkers (like mypy or pyright) that the method should override a parent method. If the parent doesn't have such a method, the type checker reports an error.

Prior Approaches:

typing_extensions.override — Backport for earlier Python versions
overrides package — Third-party library with runtime checking option
Abstract methods — Force implementation; ensures method exists in child
Documentation conventions — Comments noting override intent
Type checker configuration — Some checkers can warn about potential issues

Python Best Practice

Use @override (or typing_extensions.override) with strict type checking enabled. While Python won't prevent runtime errors, static analysis tools can catch most override mistakes before deployment. Combine with abstract base classes (ABC) for additional safety.

Real-World Override Scenarios

Let's examine scenarios where override annotations catch real bugs:

Scenario: A library updates, changing a method signature:

// Library v1.0
public class HttpClient {
    public void send(Request request) { ... }
}

// Your code
public class LoggingClient extends HttpClient {
    @Override
    public void send(Request request) {
        log("Sending: " + request);
        super.send(request);
    }
}

// Library v2.0 - signature changed!
public class HttpClient {
    public void send(Request request, Options options) { ... }
}

Without @Override: Your send(Request) silently becomes a new method. Calls go to the library's method, logging stops working, no error.

With @Override: Immediate compile error: "method does not override method from its superclass." You discover the break instantly.

Override Annotations are Documentation

Beyond error checking, @Override serves as documentation. When reading code, @Override immediately tells you 'this behavior comes from a parent class contract.' Without it, you'd need to trace the inheritance hierarchy to understand the relationship.

Override Annotation Best Practices

Based on industry experience and common failure modes, here are recommended practices:

Do's

•Always use @Override for inherited methods — 100% of the time, no exceptions
•Enable compiler/linter warnings — Configure tools to flag missing @Override
•Include interface implementations — @Override works for interfaces too (Java 6+)
•Use IDE support — Most IDEs auto-generate @Override; let them
•Apply to hashCode/equals/toString — These Object overrides are error-prone
•Keep override chains consistent — If grandchild overrides, annotate there too

Don'ts

•Don't omit 'because it's obvious' — Future maintainers may not find it obvious
•Don't assume tests catch override bugs — Silent failures often pass tests
•Don't add @Override to new methods — It's for inheritance, not arbitrary annotation
•Don't use @Override for static methods — Static methods can't be overridden
•Don't ignore IDE override warnings — They're usually right

CheckstyleConfig.xml
Checkstyle Configuration
1
2
3
4
5
6
7
8
9
<!-- Enforce @Override annotation on all overridden methods -->
<module name="MissingOverride">
    <property name="severity" value="error"/>
</module>
 
<!-- Also check interface implementations -->
<module name="MissingOverrideCheck">
    <property name="javaFiveCompatibility" value="false"/>
</module>

Summary: Making Overrides Explicit

Override annotations transform implicit relationships into explicit, compiler-verified contracts. Let's consolidate:

Key Takeaways

•Silent failures are dangerous — Typos, signature mismatches, and parent changes can cause subtle bugs that pass tests but fail in production
•@Override (Java) and override (C++) declare intent and enable compile-time verification
•Python's @override (3.12+) provides similar safety through static analysis tools
•Override annotations document relationships — Readers immediately know a method fulfills a parent contract
•Always use override annotations — The few extra characters prevent hours of debugging

What's Next:

We've covered the mechanics and annotations of method overriding. In the final page of this module, we'll connect overriding to a critical design principle: the Liskov Substitution Principle (LSP). We'll preview how proper overriding behavior isn't just about syntax, but about maintaining behavioral contracts that make substitutability safe.

Page Complete

You now understand how override annotations prevent silent failures, document intent, and enable safer refactoring. Whether @Override in Java, override in C++, or @override in Python, these markers are essential tools for maintaining polymorphic code at scale.

3 / 4

Loading learning content...

System Design (LLD)Method Overriding (Revisited)

Method Overriding — The Engine of Runtime Polymorphism

LevelIntermediate

Duration55 mins

TopicMethod Overriding (Revisited)

3 / 4

Override Annotations

Declaring Intent, Preventing Errors

What You Will Learn

The Problem Override Annotations Solve

Before we look at annotation syntax, let's understand the real problems they address. Consider this scenario:

SilentFailure.java
Java (Problematic Code)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Original parent class
public class Document {
    public String render() {
        return content;
    }
}
 
// Developer thinks they're overriding render()
public class HtmlDocument extends Document {
    
    // PROBLEM: Typo in method name!
    // This is NOT an override—it's a new method
    public String reder() {  // Oops: 'reder' instead of 'render'
        return "<html>" + getContent() + "</html>";
    }
}
 
// Later in the code...
Document doc = new HtmlDocument("Hello");
String output = doc.render();  // Calls Document.render()!
// Developer expected HTML, got plain text
// No compilation error, no runtime error
// Just wrong behavior—the worst kind of bug

Types of Override Errors:

Silent Override Failures

•Typos in method name — reder() vs render(), eqals() vs equals()
•Wrong parameter types — equals(String s) doesn't override equals(Object o)
•Extra or missing parameters — calculate(int a, int b) vs calculate(int a)
•Incompatible return type — overriding with a non-subtype return
•Parent method removal — parent class changes, child override becomes orphan
•Final method 'override' — trying to override a method marked final

@Override in Java

Syntax:

@Override
public ReturnType methodName(Parameters...) { }

What @Override Checks:

A method with the same name exists in a parent class or interface
The parameter types match exactly (proper overriding, not overloading)
The return type is compatible (same or covariant)
The parent method is not final
Visibility is not more restrictive

OverrideAnnotation.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
46
47
48
49
50
51
52
53
54
55
56
57
public class Document {
    private String content;
    
    public Document(String content) {
        this.content = content;
    }
    
    public String getContent() {
        return content;
    }
    
    public String render() {
        return content;
    }
    
    @Override
    public String toString() {
        return "Document[" + content + "]";
    }
    
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Document other = (Document) o;
        return Objects.equals(content, other.content);
    }
    
    @Override
    public int hashCode() {
        return Objects.hash(content);
    }
}
 
public class HtmlDocument extends Document {
    
    public HtmlDocument(String content) {
        super(content);
    }
    
    @Override  // <-- COMPILE ERROR if this doesn't actually override
    public String render() {
        return "<html><body>" + getContent() + "</body></html>";
    }
    
    // If we had a typo:
    // @Override
    // public String reder() {  // COMPILE ERROR: does not override
    //     return "";
    // }
    
    // If we had wrong parameters:
    // @Override
    // public boolean equals(String s) {  // COMPILE ERROR: no such method
    //     return false;
    // }
}

Best Practice: Always Use @Override

@Override and Interfaces (Java 6+):

Originally, @Override only worked for superclass methods. Since Java 6, it also works for interface implementations. This is important because interface methods can change too:

InterfaceOverride.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
public interface Renderer {
    String render(Object content);
}
 
public class JsonRenderer implements Renderer {
    
    @Override  // Works since Java 6
    public String render(Object content) {
        // If the interface changed to render(String content),
        // this @Override would immediately cause a compile error
        return new Gson().toJson(content);
    }
}

override and final in C++

C++ override Syntax:

virtual ReturnType methodName(Parameters...) override;

C++ final Syntax (prevent further overriding):

virtual ReturnType methodName(Parameters...) final;

OverrideKeyword.cpp
C++
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
51
52
53
54
#include <string>
 
class Document {
public:
    virtual ~Document() = default;
    
    virtual std::string render() const {
        return content_;
    }
    
    // Cannot be overridden by children
    virtual std::string getType() const final {
        return "Document";
    }
    
protected:
    std::string content_;
};
 
class HtmlDocument : public Document {
public:
    // CORRECT: explicitly declares override
    std::string render() const override {
        return "<html>" + content_ + "</html>";
    }
    
    // COMPILE ERROR: typo doesn't match any virtual method
    // std::string reder() const override { return ""; }
    
    // COMPILE ERROR: wrong const-ness doesn't match
    // std::string render() override { return ""; }  // Missing 'const'
    
    // COMPILE ERROR: getType() is final
    // std::string getType() const override { return "HTML"; }
};
 
class PdfDocument : public Document {
public:
    // override is optional but strongly recommended
    std::string render() const override {
        return "[PDF: " + content_ + "]";
    }
};
 
// Class marked final - cannot be inherited from
class SealedDocument final : public Document {
public:
    std::string render() const override {
        return content_;
    }
};
 
// COMPILE ERROR: cannot inherit from final class
// class ChildOfSealed : public SealedDocument {};

Key C++ Differences:

override is optional — Code compiles without it, but you lose safety checks
final prevents further overriding — The method cannot be overridden in subclasses
final on classes — The class cannot be inherited from at all
Signature matching is strict — const matters, reference qualifiers matter
Must be on virtual methods — Using override on non-virtual is an error

C++ Pitfall: Missing virtual

Override Indicators in Python

Python, being dynamically typed, doesn't have built-in override checking. Method dispatch is purely runtime, and there's no compile-time verification of override correctness.

However, Python developers have developed conventions and tools to achieve similar safety:

PythonOverrides.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
45
46
47
48
49
from abc import ABC, abstractmethod
from typing import override  # Python 3.12+
 
 
class Document(ABC):
    def __init__(self, content: str):
        self._content = content
    
    @property
    def content(self) -> str:
        return self._content
    
    @abstractmethod
    def render(self) -> str:
        """Render the document to a string format."""
        pass
 
 
class HtmlDocument(Document):
    
    # Python 3.12+ @override decorator
    # Type checker will error if this doesn't actually override
    @override
    def render(self) -> str:
        return f"<html><body>{self.content}</body></html>"
    
    # Prior to 3.12, use docstrings and type checkers:
    # def render(self) -> str:
    #     """Override Document.render to produce HTML."""
    #     return f"<html>{self.content}</html>"
 
 
# For Python < 3.12, use typing_extensions
from typing_extensions import override as override_ext
 
class PdfDocument(Document):
    
    @override_ext  # Works with mypy and pyright
    def render(self) -> str:
        return f"[PDF Document: {self.content}]"
 
 
# Third-party libraries like 'overrides' package:
# from overrides import overrides
#
# class MarkdownDocument(Document):
#     @overrides
#     def render(self) -> str:
#         return markdown.markdown(self.content)

Python's @override (3.12+):

Prior Approaches:

typing_extensions.override — Backport for earlier Python versions
overrides package — Third-party library with runtime checking option
Abstract methods — Force implementation; ensures method exists in child
Documentation conventions — Comments noting override intent
Type checker configuration — Some checkers can warn about potential issues

Python Best Practice

Real-World Override Scenarios

Let's examine scenarios where override annotations catch real bugs:

Scenario: A library updates, changing a method signature:

// Library v1.0
public class HttpClient {
    public void send(Request request) { ... }
}

// Your code
public class LoggingClient extends HttpClient {
    @Override
    public void send(Request request) {
        log("Sending: " + request);
        super.send(request);
    }
}

// Library v2.0 - signature changed!
public class HttpClient {
    public void send(Request request, Options options) { ... }
}

Without @Override: Your send(Request) silently becomes a new method. Calls go to the library's method, logging stops working, no error.

With @Override: Immediate compile error: "method does not override method from its superclass." You discover the break instantly.

Override Annotations are Documentation

Override Annotation Best Practices

Based on industry experience and common failure modes, here are recommended practices:

Do's

•Always use @Override for inherited methods — 100% of the time, no exceptions
•Enable compiler/linter warnings — Configure tools to flag missing @Override
•Include interface implementations — @Override works for interfaces too (Java 6+)
•Use IDE support — Most IDEs auto-generate @Override; let them
•Apply to hashCode/equals/toString — These Object overrides are error-prone
•Keep override chains consistent — If grandchild overrides, annotate there too

Don'ts

•Don't omit 'because it's obvious' — Future maintainers may not find it obvious
•Don't assume tests catch override bugs — Silent failures often pass tests
•Don't add @Override to new methods — It's for inheritance, not arbitrary annotation
•Don't use @Override for static methods — Static methods can't be overridden
•Don't ignore IDE override warnings — They're usually right

CheckstyleConfig.xml
Checkstyle Configuration
1
2
3
4
5
6
7
8
9
<!-- Enforce @Override annotation on all overridden methods -->
<module name="MissingOverride">
    <property name="severity" value="error"/>
</module>
 
<!-- Also check interface implementations -->
<module name="MissingOverrideCheck">
    <property name="javaFiveCompatibility" value="false"/>
</module>

Summary: Making Overrides Explicit

Override annotations transform implicit relationships into explicit, compiler-verified contracts. Let's consolidate:

Key Takeaways

•Silent failures are dangerous — Typos, signature mismatches, and parent changes can cause subtle bugs that pass tests but fail in production
•@Override (Java) and override (C++) declare intent and enable compile-time verification
•Python's @override (3.12+) provides similar safety through static analysis tools
•Override annotations document relationships — Readers immediately know a method fulfills a parent contract
•Always use override annotations — The few extra characters prevent hours of debugging

What's Next:

Page Complete

3 / 4