Dynamic binding has two forms, static and dynamic. Statically-typed dynamic binding is found in languages such as C++ (virtual functions) and Eiffel (redefinition). It is not known which function will be called for a virtual function at run-time because a derived class may override the function, in which case the overriding function must be called. Statically determining all possibilities of usage is undecidable. When the complete program is compiled, all such functions are resolved (statically) for actual objects. Formal object usage must have a consistent way of accessing these functions, as achieved thru vtables of function pointers in the actual objects (C++) or equivalent, providing statically-typed dynamic binding (this is really just defining simple function pointers with static typechecking in the base class, and filling them in in the derived class, along with offsets to reset the receiver).
The run-time selection of methods is another case of dynamic binding, meaning lookup is performed (bound) at run-time (dynamically). This is often desired and even required in many applications including databases, distributed programming and user interaction (e.g. GUIs). Examples can be found in [Garfinkel 93, p80] and [Cox 91, pp 64-67]. To extend Garfinkels example with multiple-polymorphism, a cut operation in an Edit submenu may pass the cut operation (along with parameters) to any object on the desktop, each of which handles the message in its own way (OO). If an (application) object can cut many kinds of objects such as text and graphical objects, multiple-polymorphism comes into play, as many overloaded cut methods, one per type of object to be cut, are available in the receiving object, the particular method being selected based on the actual type of object being cut (which in the GUI case is not available until run-time).
Again, various optimizations exist for dynamic lookup to increase efficiency (such as found in [Agrawal 91] and [Chambers 92]).
Dynamic binding allows new objects and code to be interfaced with or added to a system without affecting existing code and eliminates switch statements. This removes the spread of knowledge of specific classes throughout a system, as each object knows what operation to support. It also allows a reduction in program complexity by replacing a nested construct (switch statement) with a simple call. It also allows small packages of behavior, improving coherence and loose coupling. Another benefit is that code complexity increases not linearly but exponentially with lines of code, so that packaging code into methods reduces program complexity considerably, even further that removing the nested switch statement! [Martin 92] covers some of these issues.
This document was translated by ms2html v1.8 on 04.06.96.