Object-oriented design concept check: are the common reasons for overriding a superclass method to (1) extend behavior, (2) restrict or specialize behavior for a subclass context, and (3) optimize performance while preserving the contract?

Introduction / Context:
Method overriding is a core feature of object-oriented programming (OOP). A subclass supplies its own implementation of a method already defined by its superclass. This question asks whether the typical motivations include extension (adding or tailoring behavior), restriction or specialization (narrowing behavior for a specific subtype context), and optimization (improving performance without breaking the public contract).

Given Data / Assumptions:

• We are considering mainstream OOP languages (such as Java, C#, and others) with runtime polymorphism.
• Overriding should respect the method’s externally observable contract (postconditions, invariants).
• “Restriction” here refers to specialization appropriate to the subtype, not the illegal strengthening of preconditions for external callers.

Concept / Approach:
Overriding supports polymorphism: clients call a method on a base type and the subclass version executes. Common reasons include: extending behavior (adding logging, events, or subtype-specific logic), specializing behavior (adapting to subtype invariants such as different validation rules or resource lifecycles), and optimization (for example, caching results or using faster data structures) so long as externally visible effects remain contract-compatible.

Step-by-Step Solution:

Verification / Alternative check:
Use unit tests written against the base type. Substitute the subclass and verify all tests still pass, confirming that the override extends/specializes/optimizes without breaking behavior.

Why Other Options Are Wrong:

• Incorrect: Overriding for extension, specialization, and optimization is standard practice.
• Only applies to abstract methods: Concrete methods can be overridden too (subject to language rules, e.g., not final/sealed).
• Only performance optimization is valid: Overriding for domain-specific behavior is equally valid.
• Overriding is discouraged: It is foundational to polymorphism when used judiciously.

Common Pitfalls:
Violating Liskov Substitution Principle (e.g., strengthening preconditions); altering expected side effects; forgetting to call super when required; breaking invariants.

Final Answer:
Correct