High-integrity object-oriented programming with Ada - Part 3

Static Binding Vs. Dynamic Dispatch
Whether a subprogram invocation is resolved at compile time or at run time is a critical issue, and for program readability and reliability the language syntax and semantics should make the meaning clear.

In Ada, the rule can be stated fairly succinctly: A subprogram invocation X.P(…) is bound dynamically if X is of a class-wide type T'Class (or is of an access type whose designated type is such a class) and P is a primitive operation for T; otherwise the subprogram invocation is bound statically. A subprogram that is not a primitive operation thus only permits static binding. For a primitive operation, the key is whether the target of the operation—the controlling parameter—is class-wide, and this is apparent from the type of the parameter. The ability to invoke a primitive operation with either static or dynamic binding provides considerable flexibility. In contrast, Java only allows an instance method to be invoked with dynamic dispatch, although some instance methods (final or private) are not inherited so dynamic and static binding are equivalent.

There are occasions in Ada where a primitive operation on an object of a class-wide type needs to be bound statically. There are other occasions in which a primitive operation on a formal parameter having a tagged type needs to dynamically dispatch based on the tag of the actual parameter. These situations are handled by view conversions to either a specific tagged type or a class-wide type, respectively.

Operation Overriding
Misspelling the name of an overriding operation means that the superclass’s version of the operation will be implicitly inherited. For example:

package Text_Processing is
   type Text is tagged private;

   procedure Italicize ( Item : in out Text );
   ...
end Text_Processing;

package Text_Processing.Rich_Text_Processing is
   type Rich_Text is new Text with private;

   procedure Italicise (Item : in out Rich_Text);
   ...
end Rich_Text_Processing;

Because of the misspelling, Italicize for Text will be inherited by Rich_Text. To prevent this error, the recommended style is to specify overriding for each operation that is intended to override the parent type’s version:

package Text_Processing.Rich_Text_Processing is
   type Rich_Text is new Text with private;

   overriding -- Illegal
   procedure Italicise (Item : in out Rich_Text);
   ...
end Text_Processing.Rich_Text_Processing;

It is a compile-time error if overriding is specified on an operation that does not actually override an operation from the parent type. Thus the declaration of Italicise will be flagged as illegal, and the programmer can easily repair the error by spelling the name consistently.

The explicit overriding indication was introduced in Ada 2005, and so for compatibility with Ada 95 it is not required. Although an overriding declaration that does not specify overriding is thus legal, the explicit usage of overriding is strongly encouraged. This recommendation can be enforced by existing Ada development environments through coding standard checkers or compiler switches, which verify that overriding is applied to all overriding operations.

A related OOP error is to have an operation treated as overriding when it was not so intended. This situation can arise when an operation is added to a superclass, and then a subclass that declares an operation with a matching signature is recompiled. Such errors will be detected by the static analysis tool just mentioned; i.e., the given operation overrides but is not so marked. The programmer thus alerted can make the appropriate correction.