3. Binding

OODBTG Reference Model

"Binding" chooses a method or methods to be executed in responseto a request, based on the operation and objects in the request.

Note: CLOS allows method combination and may bind to multiple methods.

In classical models, the binding choice is based on the class of therecipient. In generalized models, the binding choice may depend on theclasses of several parameters.

Different object languages support different criteria and times forbinding an operation to a method for execution. Examples are "earlybinding" at compile-time and "late binding" at run-time.See entries under 11. Object Languages.

OMG Core Object Model Operation Dispatching

When an operation request is issued, a specific operation implementation(method) is selected for execution. This selection process is called operationdispatching. In the Core model, the process of selecting an implementationto invoke is based on the type of the object supplied as the controllingargument of the actual call11. The operationof the given name defined on the immediate type of the controlling argumentis chosen for invocation. In some cases this can be done at compile timewith no loss of flexibility, in others it must be delayed to executiontime.

11 The single controlling argument restrictioncan be relaxed in a component and generalized to multiple argument dispatching.


CORBA provides support for both early and late binding which are referredto as static and dynamic respectively. See entry under 1. Basic Concepts.


The model supports run-time binding of methods to objects based on thefirst argument type. (see 2.1 Operations)


EXPRESS support operator overloading only for the builtin arithmetic,etc. operators. Binding is thus a non-issue.

Open Distributed Processing

In general, the binding process involves the establishment of supportingcommunication functions and the initialization of functions. This processcontinues recursively until it is terminated by the use of binding (contexts)which already exist and can thus already support interactions. A bindingis characterized by:

Binding can refer to a process - "binding A to B". This ideacorresponds to the notion of an establishing behavior.

Binding can refer to a state of affairs - "a binding exists betweenA and B". This idea corresponds to the notion of a context. When abinding exits, there is an appearance of an end-to-end path between theobjects bound. A binding (context) represents the commitment of resourcesand the assumption of stability of aspects of a configuration. The thingmade possible by a binding is an enabled behavior.

A (necessary but not sufficient) precondition for the establishing behavioris the possession of an interface reference. The fulfillment of this preconditioncorresponds to the notion of a reference binding.

The process of unbinding corresponds to the notion of a terminationbehavior (not to be confused with an interrogation termination). In orderfor two interfaces to bind, at least one interface must posses an interfacereference to the other. This information may be passed some type of intermediary.

A binding is composed of:

an interface offer: information declaring the existence of an interfaceto which other objects may bind. The information will include the interfacereference and the interface type reference. The term service offer is equivalentbut is not used here.

an acquire: obtaining an interface offer

an acquirer: the object which obtains an interface offer

an exporting: making an interface offer available to a trader

an importing: obtaining an interface offer from the trader

Editor's Note: this is a more general definition of "binding"than is used in the current feature definition, which restricts itselfto binding a method to an operation request.

Management Information Model

Not applicable.


See 4. Polymorphism.


Binding through inheritance

Binding is supported in a straightforward manner. Functions are boundto objects through the inheritance hierarchy. Subclasses consist of allattributes, relationships, messages, and methods of the superclasses plusthose additionally specified by the user. Multiple inheritance is supportedand all instances of a subclass are instances of the superclasses.

Matisse does not allow name conflicts on attributes and relationships.Methods may be overloaded. In a multiple inheritance hierarchy, invocationof methods occurs in a left first, depth first manner which is determinedby the way the user specifies the class hierarchy.

The Matisse class hierarchy is independent of any language hierarchy.Typically, a user develops an application hierarchy that consists of persistenceand non-persistent objects. The persistence objects are mapped into theMatisse database by calls to the Matisse API (a set of C function calls).

Binding through constraints and triggers

Using the API requires the application programmer to translate objectsinto the database. A set of classes could be created to support persistentC++ or Smalltalk transparently to the programmer.

The overhead of using the API is compensated for by the gain in functionalitysupported by the database. Matisse supports constraints on attributes andrelationships, as well as pre- and post-conditions on any changes to attributesand relationships. The database will always look for these constraintsand triggers when processing. It the user has not specified any, thereis virtually no cost. As an implementation of the notion of "storedprocedures", this kind of binding is orthogonal to the inheritancehierarchy.


C++ supports both static and dynamic (run-time) binding of functioninvocations to object member functions, depending on how the member functionswere declared in class definitions. In dynamic binding, binding occursdepending on the dynamic type of the object whose member functionis being invoked. The correct operation for that object will be selectedautomatically by the run-time system. See also entries under 2.5 methodsand 4. Polymorphism.


When a method is invoked on an object, the invocation is bound to amethod implementation in the following way.

See also entry under 8. Inheritance and Delegation.


Smalltalk performs run-time binding of messages to object methods. Seealso entry under 4. Polymorphism.


Eiffel supports both late and early binding (in general this is true,however it depends on the implementation). Operations that have been redefinedthrough inheritance utilize late binding at run-time, while operationsthat have not been redefined are statically bound at compile time.

Dynamic binding occurs depending on the `dynamic' type of the receiverobject. The correct operation for that object will be selected automaticallyby the run-time system.


In Emerald, objects conceptually do not share implementation, and thereis no notion of implementation inheritance. Hence, in Emerald the choiceof a method to be executed in response to a request is limited to the singleimplementation of the operation contained in the object.


See entry under 2.3 messages.


SELF is a dynamically-typed language, and provides for run-time bindingof a message sent to an object to the method that implements the requestedoperation. SELF provides a form of classical object model in which thebinding choice is based on the receiving object itself (rather than itsclass, since SELF has no classes). See entry under 2. Objects.

System Object Model (SOM)

SOM provides support for both early and late binding. These bindingchoices are on a per method bases. See entry under 2.5 methods fora discussion of different method invocation models.

OLE Component Object Model

"Binding", meaning the choice of a method to be executed inresponse to a request, is handled by directly calling the object functionidentified in the request. OLE does not support implementation inheritance(see entry under 8. Inheritance and Delegation), so there is nodispatching by searching a class hierarchy. The term "binding"as used in the OLE context has a somewhat different meaning, relating tothe use of a type of object called a moniker in object linking.See entry under 9.6 other.

Analysis and Design Methods

SD: "In OOD it is common to definepublished operations of the same name in several different classes. Insuch a situation the selection of exactly which operation to invoke variesin a language-dependent manner."

CD: Time of binding is considered tobe a language feature. "Dynamic binding (which could also be referredto as dynamic dispatching) describes the ability of an application to chooseor bind a particular service at run time..."

RD: Time of binding is considered tobe a language feature. "...method resolution at run time (also knownas dynamic binding) [is used] to implement polymorphic operations."It "is the process of matching an operation on an object [instance]to a specific method."

JA: "The linking of the receivedstimulus to the appropriate operation to be executed is performed by bindingthe stimulus to this operation. If this binding occurs during compilation,it is said to be a static binding. ... If this binding occurs when thestimulus is actually being sent, that is during run-time, it is said tobe dynamic binding. Other names for this are late, delayed, or virtualbinding.

WD: Not used. Type checking is discussedas a language issue.

MD: "The rule known as dynamic bindingimplies that the dynamic form of the object determines which version ofthe operation is applied." "The ability of operations to automaticallyadapt to the objects to which they are applied is one of the most importantproperties of object oriented systems."

EA: Not used.

FC: "Dynamic binding is the processwhereby the actual method code for a method invocation is selected. Itis required when a method accepts arguments of any subtype of its argumenttype, and the compiler cannot determine as compile time what the actualtype of an argument is."

OA: Considered an implementation issue.

BD: Binding is determined in accordancewith the possibilities provided by the implementation language.

HA: Considered an implementation issue.

NA: "Dynamic binding[:] A mechanismpermitting different behavior to result from the same feature call."Dynamic binding is considered an essential characteristic of the analysismodel.

features matrixintro page