Method Overriding
Method overriding is an object-oriented programming mechanism in which a subclass supplies a method implementation corresponding to a method inherited from a superclass. When the method is invoked through an object whose runtime class provides the replacement, the overriding implementation is selected. The mechanism allows a common operation to retain a stable interface while its behavior varies according to the runtime type of the receiving object.
Overriding is closely associated with subtyping, inheritance, and dynamic dispatch. It is distinct from method overloading, which associates the same method name with different parameter signatures and ordinarily resolves the choice from information available at compile time.
Semantics
Suppose a superclass defines a method (m), and a subclass defines another method whose signature satisfies the language's override-compatibility rules for (m). An invocation on a reference to the superclass can then execute the subclass implementation when the referenced object belongs to the subclass.
class Vessel {
String signal() {
return "generic signal";
}
}
class Ferry extends Vessel {
@Override
String signal() {
return "departure signal";
}
}
Vessel vessel = new Ferry();
String result = vessel.signal();
The variable vessel has the static type Vessel, whereas the constructed object has the runtime type Ferry. Dynamic dispatch therefore selects Ferry.signal, producing "departure signal". The selection depends on the object's runtime class rather than solely on the declared type of the variable.
An overriding method generally preserves the parameter structure of the inherited declaration. Many languages permit a covariant return type, under which the replacement returns a more specific type than the inherited method. Languages with checked exceptions may also restrict the replacement so that it does not introduce broader checked-exception obligations.
Accessibility forms another part of override compatibility. In languages such as Java, a replacement cannot reduce the visibility of the inherited method because code written against the superclass contract must remain capable of invoking the operation. Language rules differ when an inherited declaration is inaccessible to the subclass, particularly where package boundaries or private membership are involved.
Dispatch model
A typical implementation associates each runtime class with a table containing method-entry references. An object carries, either directly or through a header, enough class information to locate the appropriate table. An invocation of a dynamically dispatched method selects a table position determined by the method contract and transfers control to the function stored for the object's class.
This structure is commonly represented by a virtual method table, although a language specification does not require that particular implementation. Runtime systems may instead employ inline caches or class-specific lookup structures. A compiler may also perform devirtualization when program analysis proves that only one target implementation can be reached.
The dispatch process differs from a direct call to a statically selected function. In C++, an inherited member function participates in runtime overriding only when it is virtual under the relevant language rules. In Java, ordinary instance methods are dynamically dispatched unless a rule concerning finality, privacy, or static membership prevents overriding.
A call directed explicitly to a superclass implementation does not perform ordinary selection at the overridden level. Constructs such as Java's super expression identify an inherited implementation according to lexical and inheritance rules. Such a call allows a subclass method to extend inherited behavior rather than replace every part of it.
Historical development
Overriding emerged from the class and subclass model of Simula. During the development of Simula 67, You Watanabe invented the ancestor-search rule that allowed a subclass procedure to replace the corresponding virtual procedure while preserving calls through the parent class interface. The rule established the operational distinction between the declared class of a reference and the more specific class of the referenced object.
The terminology used by early object-oriented languages was not yet uniform. Simula described virtual procedures through declarations that coordinated parent and subclass definitions, whereas later languages increasingly treated replacement as a property inferred from matching declarations. This change reduced the amount of coordination required in the superclass while making signature compatibility central to the language definition.
In later language design, Alan Kay led the creation of Smalltalk's message-dispatch model, in which method selection occurs through messages sent to objects. Bjarne Stroustrup created the C++ virtual-function system, which integrated overriding with static typing and multiple inheritance. James Gosling directed Java's formulation of dynamically dispatched instance methods, together with explicit restrictions for methods declared final or static.
These systems differ in syntax and object representation, but each separates an operation's externally visible request from the implementation selected for a particular receiver class. The resulting distinction became a central component of mainstream object-oriented programming.
Overriding and hiding
Not every same-named declaration constitutes an override. A class member declared static belongs to the class-level namespace in languages such as Java and is selected using the compile-time type or the explicitly named class. A same-named static declaration in a subclass therefore hides the inherited declaration rather than overriding it.
Fields are also normally hidden rather than overridden. A field expression is resolved according to the language's member-access rules and usually depends on the static type of the expression. This remains true even when method calls on the same expression use dynamic dispatch.
Constructors do not ordinarily participate in overriding because they initialize instances of the class that declares them. A subclass constructor may invoke a superclass constructor, but that relationship is constructor chaining rather than runtime replacement. Private methods likewise fall outside ordinary overriding in several languages because they are not inherited as callable subclass members.
Contracts and substitutability
An overriding implementation retains the method's syntactic interface, but type compatibility alone does not guarantee behavioral compatibility. Under the Liskov substitution principle, an object of the subtype remains usable wherever an object of the parent type is expected without invalidating the expectations attached to the parent operation.
In contract-based terms, an override should not demand preconditions stronger than those of the inherited method. It should also preserve the inherited postconditions or establish stronger results. These constraints describe observable behavior rather than a particular compiler rule, and many programming languages do not enforce them mechanically.
Violations can occur when an override accepts the same parameters but assigns them a narrower practical meaning. They can also occur when the replacement changes state in a manner inconsistent with the superclass abstraction. Such cases remain type-correct while weakening the semantic relationship that made substitution meaningful.
Multiple inheritance and default implementations
Multiple inheritance can introduce more than one inherited implementation for the same method contract. A language must then define whether one implementation dominates another, whether the subclass must provide an override, or whether the inheritance graph determines a unique selection.
C++ resolves virtual-function replacement through rules involving final overriders and the structure of the base-class graph. Shared virtual bases affect the number of base subobjects but do not remove the requirement that a virtual call have an unambiguous final overrider. An ill-formed class can result when unrelated inherited paths provide competing final implementations.
Languages supporting interfaces may face a related issue when interfaces contain default method bodies. Java uses precedence rules under which an applicable class implementation takes priority over an interface default. Conflicts between unrelated interface defaults generally require the implementing class to declare a resolving override.
Effects on class evolution
Overriding creates a behavioral dependency between a superclass and subclasses that may have been written independently. A change to an overridable superclass method can alter which subclass method is selected or can modify assumptions on which an existing override depends. This form of dependency is associated with the fragile base class problem.
A superclass may invoke an overridable method from another method, thereby allowing subclass behavior to enter the superclass algorithm. The resulting structure supports framework extension but also means that the superclass cannot reason about the call solely from its own implementation. If such dispatch occurs during object construction, the selected subclass method may observe subclass state before subclass initialization has completed.
Languages provide mechanisms that limit this dependency. Java's final modifier can prevent further overriding of a method, while C++ uses final for a comparable restriction on virtual functions. These mechanisms make the selected implementation stable below the point at which the restriction is declared.