Report

7a:T5e8,// Parent class with a method to be overridden public class Document { private String content; public Document(String content) { this.content = content; } public String getContent() { return content; } // Method that subclasses will override public String render() { return content; // Default: return raw content } } // Child class that OVERRIDES the render method public class MarkdownDocument extends Document { public MarkdownDocument(String content) { super(content); } @Override // Annotation indicates intentional override public String render() { // Convert Markdown to HTML (simplified) return convertMarkdownToHtml(getContent()); } private String convertMarkdownToHtml(String markdown) { // Process **bold**, *italic*, etc. return markdown .replaceAll("\*\*(.+?)\*\*", "$1") .replaceAll("\*(.+?)\*", "$1"); } } // Another child class with its own override public class RichTextDocument extends Document { public RichTextDocument(String content) { super(content); } @Override public String render() { // Apply rich text styling return applyRichTextFormatting(getContent()); } private String applyRichTextFormatting(String text) { // RTF-specific processing return "

" + text + "

"; } }7b:T57a,# Parent class with a method to be overridden class Document: def __init__(self, content: str): self._content = content @property def content(self) -> str: return self._content # Method that subclasses will override def render(self) -> str: return self._content # Default: return raw content # Child class that OVERRIDES the render method class MarkdownDocument(Document): def __init__(self, content: str): super().__init__(content) def render(self) -> str: """Override to convert Markdown to HTML.""" return self._convert_markdown_to_html(self.content) def _convert_markdown_to_html(self, markdown: str) -> str: import re # Process **bold**, *italic*, etc. result = re.sub(r'\*\*(.+?)\*\*', r'\1', markdown) result = re.sub(r'\*(.+?)\*', r'\1', result) return result # Another child class with its own override class RichTextDocument(Document): def __init__(self, content: str): super().__init__(content) def render(self) -> str: """Override to apply rich text formatting.""" return self._apply_rich_text_formatting(self.content) def _apply_rich_text_formatting(self, text: str) -> str: # RTF-specific processing return f"

{text}

"7c:T61a,public class DocumentProcessor { public void processAndDisplay(Document document) { // The reference type is Document (parent class) // But the actual object could be ANY subclass String rendered = document.render(); // Which render() runs? System.out.println("=== Rendered Output ==="); System.out.println(rendered); System.out.println("======================="); } public static void main(String[] args) { DocumentProcessor processor = new DocumentProcessor(); // Three different document types Document plain = new Document("Just plain text"); Document markdown = new MarkdownDocument("This is **bold** and *italic*"); Document richText = new RichTextDocument("Formatted content here"); // ALL stored as Document references // But each calls its OWN render() implementation! processor.processAndDisplay(plain); // Output: Just plain text processor.processAndDisplay(markdown); // Output: This is bold and italic processor.processAndDisplay(richText); // Output:

Formatted content here

// We can even collect them: Document[] documents = { plain, markdown, richText }; for (Document doc : documents) { // Same method call, THREE different behaviors! processor.processAndDisplay(doc); } } }7d:T52e,class DocumentProcessor: def process_and_display(self, document: Document) -> None: # The type hint is Document (parent class) # But the actual object could be ANY subclass rendered = document.render() # Which render() runs? print("=== Rendered Output ===") print(rendered) print("=======================") def main(): processor = DocumentProcessor() # Three different document types plain = Document("Just plain text") markdown = MarkdownDocument("This is **bold** and *italic*") rich_text = RichTextDocument("Formatted content here") # ALL referenced through their parent type # But each calls its OWN render() implementation! processor.process_and_display(plain) # Output: Just plain text processor.process_and_display(markdown) # Output: This is bold and italic processor.process_and_display(rich_text) # Output:

Formatted content here

# We can even collect them in a list: documents: list[Document] = [plain, markdown, rich_text] for doc in documents: # Same method call, THREE different behaviors! processor.process_and_display(doc) if __name__ == "__main__": main()7e:T60c,public class DocumentFactory { public Document createDocument(String type, String content) { // The return type is Document (parent class) // The compiler cannot know which ACTUAL type will be created if (type.equals("markdown")) { return new MarkdownDocument(content); } else if (type.equals("richtext")) { return new RichTextDocument(content); } else if (type.equals("pdf")) { return new PdfDocument(content); } else { return new Document(content); // Plain document } } } public class Application { public static void main(String[] args) { DocumentFactory factory = new DocumentFactory(); // The "type" comes from user input, config file, database, etc. String docType = getUserInput(); // Could be ANYTHING // Compiler knows this is a Document // But cannot know if it's Markdown, RichText, PDF, or plain Document doc = factory.createDocument(docType, "Hello world"); // Which render() implementation should run? // The compiler CANNOT know—the value of docType is only // known at RUNTIME when the user provides input! String result = doc.render(); System.out.println(result); } private static String getUserInput() { // Simulating runtime input java.util.Scanner scanner = new java.util.Scanner(System.in); return scanner.nextLine(); } }7f:T4c4,class DocumentFactory: def create_document(self, doc_type: str, content: str) -> Document: """ The return type is Document (parent class). The interpreter doesn't know which ACTUAL type will be created until this method is called at runtime. """ if doc_type == "markdown": return MarkdownDocument(content) elif doc_type == "richtext": return RichTextDocument(content) elif doc_type == "pdf": return PdfDocument(content) else: return Document(content) # Plain document def main(): factory = DocumentFactory() # The "type" comes from user input, config file, database, etc. doc_type = input("Enter document type: ") # Could be ANYTHING # Type-checker knows this is a Document # But cannot know if it's Markdown, RichText, PDF, or plain doc: Document = factory.create_document(doc_type, "Hello world") # Which render() implementation should run? # Python CANNOT know until runtime—the value of doc_type is only # known when the user provides input! result = doc.render() print(result) if __name__ == "__main__": main()80:Ta9d,public abstract class ReportGenerator { // Template method — defines the algorithm structure // Marked final so subclasses can't change the structure public final String generateReport(List data) { String header = createHeader(); // May be overridden String body = formatData(data); // May be overridden String footer = createFooter(); // May be overridden String styled = applyTheme(header + body + footer); // May be overridden return styled; } // Hooks — meant to be overridden protected String createHeader() { return "=== Report === "; // Default implementation } // Abstract — MUST be overridden protected abstract String formatData(List data); // Hooks — meant to be overridden protected String createFooter() { return " === End ==="; // Default implementation } protected String applyTheme(String content) { return content; // No styling by default } } // Subclass for HTML reports public class HtmlReportGenerator extends ReportGenerator { @Override protected String createHeader() { return "Report "; } @Override protected String formatData(List data) { StringBuilder html = new StringBuilder(""); for (DataPoint point : data) { html.append(""); } html.append("

").append(point.getLabel()) .append("

").append(point.getValue()) .append("

"); return html.toString(); } @Override protected String createFooter() { return ""; } @Override protected String applyTheme(String content) { // Add CSS styling return content.replace("", ""); } } // Subclass for CSV export public class CsvReportGenerator extends ReportGenerator { @Override protected String createHeader() { return "label,value "; // CSV header row } @Override protected String formatData(List data) { StringBuilder csv = new StringBuilder(); for (DataPoint point : data) { csv.append(point.getLabel()).append(",") .append(point.getValue()).append(" "); } return csv.toString(); } @Override protected String createFooter() { return ""; // No footer for CSV } // applyTheme not overridden — CSV doesn't support styling }72:{"json":{"id":"seed_b39e89e035e61b36320a11ac5bd3a151","slug":"method-overriding-revisited","category":"System Design (LLD)","topic":"Method Overriding (Revisited)","title":"Method Overriding — The Engine of Runtime Polymorphism","description":"Master method overriding as the mechanism that enables runtime polymorphism. Explore virtual method dispatch, override annotations, and the deep connection between overriding and the Liskov Substitution Principle in producing truly flexible, substitutable object-oriented designs.","difficulty":"INTERMEDIATE","estimatedMinutes":55,"pages":[{"id":"seed_81ca3cfed422a38fdea5fdb70d3d30cf","title":"Overriding for Polymorphic Behavior","order":0,"content":[{"id":"opening-hook","title":"The Heart of Runtime Polymorphism","content":[{"data":{"content":"In our exploration of inheritance, we learned that method overriding allows subclasses to replace inherited behavior with specialized implementations. But that was only half the story. **Overriding isn't just about customization—it's the fundamental mechanism that makes runtime polymorphism possible.**\n\nWhen you call a method on an object reference, and the actual object might be of any subtype, how does the system know which implementation to execute? The answer lies in the sophisticated interplay between overriding and dynamic method dispatch. This connection transforms simple code reuse into something far more powerful: behavior that adapts based on actual object types at runtime."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you'll understand why method overriding is inseparable from polymorphism, how overriding enables substitutability, the mechanics of how overridden methods get selected at runtime, and why this mechanism is central to flexible object-oriented design.","variant":"info"},"type":"callout"}]},{"id":"revisiting-method-overriding","title":"Revisiting Method Overriding","content":[{"data":{"content":"Before connecting overriding to polymorphism, let's ensure we have a precise understanding of what method overriding actually means:\n\n**Method Overriding** occurs when a subclass provides a specific implementation for a method that is already defined in its parent class. The method in the subclass must have:\n\n1. **The same name** as the method in the parent\n2. **The same parameter signature** (types and order of parameters)\n3. **A compatible return type** (same type or a subtype, known as covariant return)\n4. **Equal or less restrictive access** (e.g., protected can become public, not the reverse)\n\nWhen these conditions are met, the subclass method *replaces* the parent's implementation for instances of the subclass."},"type":"text"},{"data":{"fileName":"BasicOverriding.java","languages":[{"code":"$7a","label":"Java","value":"java"},{"code":"$7b","label":"Python","value":"python"}]},"type":"code"},{"data":{"content":"In this example, both `MarkdownDocument` and `RichTextDocument` **override** the `render()` method from `Document`. Each provides a specialized implementation appropriate to its document type. So far, this is basic inheritance—customization of behavior in subclasses.\n\nBut here's where things get interesting: **What happens when we store these objects in a variable typed as the parent class?**"},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"overriding-enables-polymorphism","title":"Overriding Enables Polymorphism","content":[{"data":{"content":"The true power of overriding emerges when we work with objects through parent-class references. This is the essence of runtime polymorphism:\n\n**The declared type determines *what* you can call. The actual type determines *which implementation* runs.**\n\nLet's see this in action:"},"type":"text"},{"data":{"fileName":"PolymorphismInAction.java","languages":[{"code":"$7c","label":"Java","value":"java"},{"code":"$7d","label":"Python","value":"python"}]},"type":"code"},{"data":{"icon":"Sparkles","title":"The Polymorphic Magic","content":"Notice how `processAndDisplay()` doesn't know or care which specific Document type it receives. It calls `render()` on the Document reference, but the ACTUAL behavior depends on what TYPE of object is behind that reference. This is polymorphism—the same interface (the `render()` method) produces different behavior (many forms) based on the actual object type.","variant":"tip"},"type":"callout"},{"data":{"content":"**Why is this powerful?**\n\nWithout polymorphism through overriding, the `processAndDisplay` method would need to know every possible document type and have conditional logic to handle each one:\n\n```java\n// WITHOUT polymorphism - fragile and unmaintainable\npublic void processAndDisplay(Document document) {\n String rendered;\n \n if (document instanceof MarkdownDocument) {\n rendered = ((MarkdownDocument) document).renderMarkdown();\n } else if (document instanceof RichTextDocument) {\n rendered = ((RichTextDocument) document).renderRichText();\n } else {\n rendered = document.getContent();\n }\n \n // Every new document type requires modifying this method!\n}\n```\n\nWith polymorphism through overriding:\n- Adding a new document type requires NO changes to `processAndDisplay`\n- The method is shorter, clearer, and more maintainable\n- New types work automatically as long as they override `render()` appropriately"},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"substitutability-connection","title":"The Substitutability Connection","content":[{"data":{"content":"Polymorphism through overriding isn't just a convenient trick—it embodies a fundamental principle of object-oriented design: **substitutability**.\n\n**Substitutability** means that wherever code expects an object of a parent type, any subtype object can be used in its place without breaking correctness. This is formalized as the **Liskov Substitution Principle (LSP)**, which we'll explore in depth later.\n\nOverriding is what makes substitutability work:\n\n1. **The parent class defines the contract** — the method signature and expected behavior\n2. **Subclasses override to fulfill the contract** — providing their own implementation\n3. **Client code works with the contract** — calling methods on parent-type references\n4. **The runtime selects the right implementation** — matching actual object types to their overridden methods"},"type":"text"},{"data":{"height":"450px","mermaidSyntax":"graph TB\n subgraph Client[\"Client Code\"]\n CC[\"processAndDisplay(Document doc)\"]\n MC[\"doc.render()\"]\n end\n \n subgraph Contract[\"Contract (Parent Class)\"]\n DOC[\"Document\"]\n RM[\"render(): String\"]\n end\n \n subgraph Implementations[\"Substitutable Implementations\"]\n MD[\"MarkdownDocument\"]\n MDR[\"render(): HTML output\"]\n RTD[\"RichTextDocument\"]\n RTDR[\"render(): RTF output\"]\n PDF[\"PdfDocument\"]\n PDFR[\"render(): PDF output\"]\n end\n \n CC --> |\"Works with contract\"| DOC\n DOC --> |\"Defines\"| RM\n \n MD --> |\"Overrides\"| RM\n MD --> MDR\n RTD --> |\"Overrides\"| RM\n RTD --> RTDR\n PDF --> |\"Overrides\"| RM\n PDF --> PDFR\n \n MC --> |\"Runtime selects\"| MDR\n MC --> |\"Runtime selects\"| RTDR\n MC --> |\"Runtime selects\"| PDFR\n \n style DOC fill:#e1f5fe\n style MD fill:#c8e6c9\n style RTD fill:#c8e6c9\n style PDF fill:#c8e6c9"},"type":"mermaid-excalidraw"},{"data":{"content":"**Key insight:** The client code (`processAndDisplay`) is **decoupled** from specific implementations. It depends only on the abstraction (the `Document` class and its `render()` contract). This means:\n\n- **You can add new document types** without modifying the processor\n- **You can change how MarkdownDocument renders** without affecting other code\n- **You can test with mock Documents** that override `render()` for predictable testing\n\nThis decoupling is the practical benefit of substitutability—and it's only possible because overriding exists."},"type":"text"},{"data":{"icon":"AlertCircle","title":"Substitutability Requires Proper Overriding","content":"For substitutability to work correctly, overriding methods must honor the *behavioral* contract of the parent—not just the signature. A MarkdownDocument that overrides `render()` to delete the document content instead of rendering it would break substitutability. The signature would match, but the behavior would violate expectations. This is why LSP matters.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"why-runtime","title":"Why Overriding Must Be Resolved at Runtime","content":[{"data":{"content":"A critical question emerges: **Why can't the compiler figure out which overridden method to call?**\n\nThe answer reveals why runtime polymorphism requires *dynamic* dispatch:\n\n**Compile Time vs. Runtime Type Information:**\n\nAt compile time, the compiler only knows the *declared* (static) type of a variable. At runtime, the JVM/interpreter knows the *actual* (dynamic) type of the object."},"type":"text"},{"data":{"fileName":"RuntimeDetermination.java","languages":[{"code":"$7e","label":"Java","value":"java"},{"code":"$7f","label":"Python","value":"python"}]},"type":"code"},{"data":{"content":"**The critical insight:** In this example, the actual type of `doc` depends on user input. There's no way for static analysis to predict it. The decision about which `render()` to call **must** wait until execution time.\n\nThis is true for many real-world scenarios:\n\n- **Configuration-driven instantiation**: Object types determined by config files\n- **Database-driven polymorphism**: Object types based on database records\n- **Plugin architectures**: Object types loaded dynamically at runtime\n- **Deserialization**: Object types determined by incoming data\n\nIn all these cases, **compile-time resolution is impossible**. The system must delay method selection until runtime—which is exactly what virtual method dispatch provides."},"type":"text"},{"data":{"items":["**Factory patterns** — The factory returns a parent type, actual subtype chosen dynamically","**Dependency injection** — Concrete types injected at runtime, referenced by interface/parent type","**Collections of mixed types** — List containing various document subtypes","**External input** — User choices, network data, or file content determining object types","**Plugin systems** — Classes loaded and instantiated at runtime via reflection"],"title":{"icon":"Target","text":"When Runtime Resolution Is Required","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":4},{"id":"design-impact","title":"The Design Impact of Polymorphic Overriding","content":[{"data":{"content":"Understanding that overriding enables runtime polymorphism fundamentally changes how we design systems. Here are the key implications:"},"type":"text"},{"data":{"left":[{"data":{"items":["**Open/Closed Principle** — Code is open for extension (new subtypes) but closed for modification","**Reduced conditionals** — No need for if/else chains checking types","**Natural extensibility** — New types integrate seamlessly","**Testability** — Mock objects can override methods for isolated testing","**Plugin architectures** — Third parties can add types without access to source"],"title":{"icon":"CheckCircle","text":"Design Benefits","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Define clear contracts** — Parent methods must have well-defined expectations","**Document behavioral requirements** — What should overrides guarantee?","**Use defensive design** — Validate inputs, don't assume correct overrides","**Consider final methods** — Some operations shouldn't be overridable","**Plan for extension** — Design parent classes knowing they'll be extended"],"title":{"icon":"AlertCircle","text":"Design Responsibilities","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Real-World Design Pattern: Template Method**\n\nOne of the clearest illustrations of overriding for polymorphism is the Template Method pattern. The parent class defines the *structure* of an algorithm, while subclasses override specific steps:"},"type":"text"},{"data":{"fileName":"TemplateMethodPattern.java","languages":[{"code":"$80","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"In this pattern:\n\n- The `generateReport()` method defines the common algorithm structure\n- Individual steps (`createHeader`, `formatData`, etc.) are overridden for customization\n- Client code works with `ReportGenerator` references—it doesn't know if it's getting HTML, CSV, PDF, or any other format\n- **Polymorphism through overriding** allows the same algorithm template to produce vastly different outputs"},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"summary","title":"Summary: Overriding as Polymorphism's Foundation","content":[{"data":{"content":"We've established the critical connection between method overriding and runtime polymorphism. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Overriding provides the 'many forms'** — Each subclass's override is a different form that a polymorphic call can take","**Declared type vs. actual type** — References are typed as parents, but actual objects are subtypes with overridden behavior","**Runtime resolution is essential** — Since the actual type is often unknowable at compile time, method dispatch must happen at runtime","**Substitutability becomes possible** — Any subtype can be used where the parent type is expected, because overrides fulfill the parent's contract","**Design becomes flexible** — Client code depends on abstractions, not concrete types, enabling extension without modification"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that we understand *why* overriding enables polymorphism, we need to understand *how* the runtime actually selects the right override to execute. In the next page, we'll dive deep into **Virtual Method Dispatch**—the mechanism that makes this magic happen under the hood."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand how method overriding serves as the mechanism enabling runtime polymorphism. Overriding isn't just about customization—it's what allows the same method call to exhibit different behaviors based on actual object types. This is the heart of flexible, substitutable object-oriented design.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":6}],"isLocked":false},{"id":"seed_2797d134669e2d4290790991125a6bf3","title":"Virtual Method Dispatch","order":1,"content":null,"isLocked":true},{"id":"seed_c7b2381519f4839937615cca8f2950f9","title":"Override Annotations","order":2,"content":null,"isLocked":true},{"id":"seed_0c8160aace49bbb5d67565a4171f190b","title":"Overriding and Liskov Substitution Preview","order":3,"content":null,"isLocked":true}]}}