features matrixintro pageOODBTG Reference Model
"Polymorphism" means that the binding of a request involvesa choice among alternative implementations of the operation. Polymorphismallows "overloading" of operations, which means that an operationmay be implemented in several alternative methods, associated with differentclasses of parameters.
OMG Core Object Model
The Core Object Model supports the kind of polymorphism generated bysubtyping, and does not rule out other forms of polymorphism. See entriesunder 2.2 requests, 7. Types and Classes, and 8. Inheritanceand Delegation.
OMG CORBA IDL
Polymorphism is not addressed in the CORBA specification since the specificationonly deals with interfaces and not the object implementation. The specificationdoes not preclude multiple object implementations supporting the same CORBAinterface.
ODMG
The model supports polymorphism implicit in subtyping, as well as parameterizedcollection types.
EXPRESS
No notion of polymorphism. A function call activates a function. Thenumber and type of the actual parameters must agree with the formal parametersdefined for that function.
Open Distributed Processing
A fundamental notion of ODP, used extensively. The property of satisfyingmany types is known as polymorphism (literally: many forms). Polymorphismis the property that instances of one type can also behave or be treatedas though they are instances of another type. Subtyping automatically generatespolymorphism, but the two concepts are independent.
Management Information Model
For a managing and managed system to interoperate, they must both beaware of the managed object classes that will be used during communication.However, there is also a requirement to maintain interoperability wheneither the managed system or the managed object class definitions are enhanced.Allomorphism allows newly defined object classes (which are extensionsof more general object classes) to be instantiated to satisfy specificmanagement needs, while still permitting communication based on the definitionsof the more general object classes. This concept is valuable for upgradingmanaged object class definitions in one system without simultaneously upgradingthe other system. For example, if a managed object class definition isupgraded in a managed system, but the managing system has not been upgraded,allomorphism allows both systems to be able to communicate using the formermanaged object class definition. In this example in the managed system,the managed object class is changed (as far as the interface is concerned),but still compatible with a former managed object class and instances stillmay behave as if they are instantiations of the former managed object class.
Allomorphism is a property of a managed object instance, not of a managedobject class; that is, the object classes that an object instance may beallomorphic to is decided at the time of the creation of the instance andnot at the time of the instance's class definition. An instance of a managedobject class may only behave allomorphically with instances of a compatibleobject classes.
By use of allomorphism, it is possible to treat a managed object asif it were a member of a class other than the actual instantiated class.Thus, allomorphism simply refers to the capability of a managed objectto "act" as if it were a member of another class. An instanceof a managed object class (the extended managed object) may behave as allomorphicto a compatible object class. The behavior definition of the extended managedobject class should not contradict the behavior of the compatible objectclass.
SQL3
Different routines may have the same name. This is referred to as overloading,and may be required, for example, to allow an ADT subtype to redefine anoperation inherited from a supertype. SQL3 implements what is sometimesknown as a generalized object model, meaning that the types of allarguments of a routine are taken into consideration when determining whatroutine to invoke, rather than using only a single type specified in theinvocation as, for example, in C++ or Smalltalk. As a result, the rulesfor determining which routine to invoke for a given invocation can be fairlycomplex. The instance of the routine that is chosen for execution is thebest match given the types of the actual arguments of the invocation atrun time.
Matisse
Polymorphism is supported by the binding mechanism described in theMatisse entry under 3. Binding
C++
C++ supports polymorphism by allowing member functions defined in classesto be overridden with member functions having the same names (operatoroverloading), but different implementations, in derived classes (subclasses).In selecting the appropriate member function to call in response to a functioninvocation, C++ distinguishes between the static type of a referenceand the dynamic type of the object it refers to at a given point. The dynamic type must be a descendant of the static type. The invocationis type-checked based on the static type of the reference. If the functioncalled is a virtual member function, the member function associated withthe actual object pointed to is called dynamically at run time. If thefunction is non-virtual, the call will have been statically bound to themember function of the reference's class at compile time. See also entriesunder 7. Types and Classes and 8. Inheritance and Delegation.
OOCOBOL
Polymorphism is a feature that allows a given statement to do differentthings. In OO COBOL, the ability for a data item to contain various objectsof different classes means that a method invocation on that data item canbe bound to one of many possible methods. Sometimes the method can be identifiedbefore execution, but in general, the method cannot be identified untilrun time.
A data item can be declared to contain objects of a given class or anydescendant of that class; it can also be declared to contain objects thatconform to a given interface. When a given interface is used, the classesof the conforming objects may be completely unrelated. These options arespecified using the various forms of the USAGE IS OBJECT REFERENCE declarationfor data items, as given below:
[ interface-name-1 ] [ ] [ [ { CLASS-OBJECT } ] ] OBJECT REFERENCE [ [ { } OF ] SELF ] [ [ { CLASS } ] ] [ ] [ [ CLASS-OBJECT OF ] class-name-1 [ONLY] ]See also entry under 8. Inheritance and Delegation.
Smalltalk
Polymorphism is the way that the Smalltalk language allows methods ofsame name to have predictable and meaningful results in related instances,yet perform the operations differently to achieve similar results.
Smalltalk supports polymorphism by allowing methods defined in classesto be overridden with methods of the same name, but different logic, ina subsequent subclass. In addition, methods of the same name can be definedin a total different subclass hierarchy.
In the class hierarchy below, all of the lowest level classes are definedto accept the message "moveForward," but several different versionsare implemented as indicated by (MFn) in the diagram.The message sent to the instances of "Bus" or "Auto"uses the method defined in the "Motorized" class. The same methodis inherited by "Train" and "Motorcycle," but bothhave overridden the inherited method by defining a method with differentlogic using the same message pattern. All the others instances in the diagramhave the "moveForward" message pattern in their interface, butare not in the motorized inheritance chain. All of the "moveForward"methods function as you intuitively expect.
Transport Mechanism (mFabstract) /------------------ | --------------------\ Animal Powered Human Powered Motorized / (mF1) \ / \ / (mF5) \Buggy Wagon Land-based Water-based Public Private / \ / (mF4) \ / \ / \ Bike Skates Row Boat Canoe Bus Train Auto Motorcycle (mF2) (mF3) (mF6) (mF7)
Eiffel
Eiffel allows entities to be attached to different object types at run-time.Polymorphism in Eiffel is constrained by inheritance. Only those objectsthat `conform' to the declared type are allowed to be attached. Conformanceof an object includes its declared type and any direct or indirect descendants.
For example, given class A, and subclasses of A being B and C. An entitydeclared as:
entity: A
can be attached to objects of type A, B and C.
Static typing ensures that there will be at least one version of alloperations requested by a client.
Emerald
Emerald supports a number of forms of polymorphism. In Emerald, alloperations are naturally polymorphic (i.e., work "correctly"regardless of the types of their arguments) because objects (of differenttypes) may be used as arguments provided they conform to the typesdeclared for the formal parameters of the operation (a form of inclusionpolymorphism). See entry under 7. Types and Classes, for a discussionof conformity. Emerald supports user-defined operations that return types(type objects), subject only to the constraint that the types of variables,constants and formal parameters be evaluable at compile-time. Since typesare objects, types may be passed as arguments to functions that createtypes (i.e., parameterized type constructors). This is a form of parametricpolymorphism. Objects in Emerald are also polymorphic, in the sensethat they can be used in situations requiring different types; e.g., anobject can be assigned to any identifier provided that the object's typeconforms to that declared for the identifier.
SELF
SELF supports the form of polymorphism provided by run-time bindingof a message sent to an object to the method that implements the requestedoperation. Since SELF is classless, the method that implements a givenoperation can potentially differ for each object (instance) thatdefines that operation, rather than just for each class. See entry under3. Binding.
System Object Model (SOM)
The polymorphism provided by SOM depends on the method dispatching schemeselected. If "offset resolution" is used then a static schemefor typing objects is used and polymorphism is based strictly on classinheritance. If the "name resolution" method dispatching is usedthen methods are located dynamically and polymorphism is based on the actualprotocols that objects honor.
OLE Component Object Model
The Component Object Model is polymorphic in the sense that what appearsto be the same request can be sent to any interface supporting the requestedoperation; the interfaces need not refer to objects of the same class.However, unlike models supporting a "conventional" subtypingmechanism for objects having a single interface, the interfaces in WindowsObjects remain distinct. Through a pointer to a Y interface, the objectcannot be treated as an X, even if the object also has an X interface;instead, the user must explicitly get a pointer to the X interface.
Analysis and Design Methods
SD: "At design time, a polymorphicinvocation is a invocation of one of a set of instance-based publishedoperations, where all of the published operations in the set have the samemodule name but differing class names. When indicating a polymorphic invocation,the designer is stating that (1) the published operations to be invokedwill be selected at run time, and (2) the selection will be based on thetype of the instance."
CD: [It appears to the present editorthat Coad has successfully described a method of 'object-oriented' analysisand design without invoking the concept polymorphism.]
RA: "The same operation may applyto many different classes. Such an operation is polymorphic: that is, thesame operations takes on different forms in different classes."
JA: "Polymorphism means that thesender of a stimulus does not need to know the class of the receiving instance."See 3. Binding.
WD: "Polymorphism is the abilityof two or more classes of object to respond to the same message, each inits own way."
MD: "Polymorphism means the abilityto take several forms. In object oriented programming this refers to theability of an entity to refer at run-time to instances of various classes.""This kind of polymorphism does not involve objects changing theirform a run time, or being converted from one format to another, it simplymeans that a given entity may refer to objects of various kinds.""...[E]very ... entity has a static type (class) and the dynamic typesit may take are restricted to the descendants of that class. "
EA: Apparently not used.
FD: "The same method [may] applyto two different classes, perhaps taking on different implementations (thusmaking it polymorphic.) "
OA: "An operation may have morethan one method defined for it. ... One common reason for multiple methodsis due to differences between the input variables. ... In other words,the same operation can support different types of objects-each with itsown method. This phenomenon is known as polymorphism..."
BD: "... [P]olymorphism ... representsa concept in type theory in which a single name (such as a variable declaration)may denote objects of many different classes that are related by some commonsuperclass. Any object denoted by this name is therefore able to respondto some common set of operations. The opposite of polymorphism is monomorphism,which is found in all languages that are both strongly typed and staticallybound, such as Ada."
HA: "Polymorphism is the abilityof abstractions to share services. It can be defined as 'a concept in typetheory in which a name may denote objects of many different classes relatedby some common base class. Thus, any object denoted by this name is ableto respond to some common set of operations in different ways' (Booch andVilot, 1990b). "
NA: "Polymorphism[:] A mechanismby which a named reference ... can be attached to objects of differenttype at different points in time."features matrixintro page