Ops(T)there exists a corresponding operation WSjOps(S)such that the following conditions hold:OODBTG Reference Model
"Inheritance" and "delegation" both involve derivingnew definitions from existing ones.
In "class-class inheritance", classes are arranged as nodesin a graph, with unidirectional links between nodes defining inheritancepaths. "Subclasses" ("derived classes") are "specializations"of their more general parent classes. "Superclasses" ("baseclasses") represent "generalization" of their child classes.
Conflicting definitions of protocol, behavior, and state may be inheritedalong paths of the inheritance graph and are resolved in system-dependentways. Different "conflict resolution" and "method combination"strategies are used in different systems to define the semantics of inheritance.When creating a subclass, attributes and operations may be added to thoseinherited from the superclasses, or they may selectively "override"(replace), or "block" (hide) those from the superclass.
The two most common forms of class-class inheritance are "singleinheritance", where the graph is a tree, and "multiple inheritance",where the graph is a directed acyclic graph.
In "class-instance inheritance", instances of a class inherita common interface and an initial state (default or initial values of certainattributes) from the class.
In "delegation", which can be characterized as "instance-instanceinheritance", an object assigns or transfers behavioral definitionsor implementations or state to another object. Some delegation-based systemsdo not differentiate between class and instances. Object-to-object delegationgeneralizes both class-class inheritance and class-instance inheritance.
OMG Core Object Model
4.2.6 Subtyping and inheritance
Subtyping is a relationship between types based on their interfaces.It defines the rules by which objects of one type are determined to beacceptable in contexts expecting another type. Inheritance is amechanism for reuse. It allows a type to be defined in terms of anothertype. Many object systems do not distinguish between subtyping and inheritance.This section defines the two concepts separately, but then explicitly stateshow they are related in the Core Object Model.
4.2.6.1 Subtyping
The Core Object Model supports subtyping for Object types. Intuitivelyone type is a subtype of another if the first is a specialization or arefinement of the second. Operationally, this means that any object ofthe first type can be used in any context which expects an object of thesecond type; that is, if S is a subtype of T, an object of type S may beused wherever an object of type T may be used. In other words, objectsof type S are also of type T. Subtypes can have multiple parent types,with the implication that an object that is an instance of a type S isalso an instance of all supertypes of type S. The relationships betweentypes define a type hierarchy, which can be drawn as a directed acyclicgraph.
An object is a direct instance of a type if it is an instance of thattype and not an instance of any subtype of that type. The Core Object modelrestricts objects to be direct instances of exactly one type. That onetype is the object's immediate type. The Core Object model has nomechanism for an object to change its immediate type.
In the Core Model, the type designer is required to declare the intentthat a type S is a subtype of T. Formally, if S is declared to be a subtypeof T (and conversely, T is a supertype of S), then for each operation WTiOps(T)there exists a corresponding operation WSjOps(S)such that the following conditions hold:
1. the name of the operations match
2. the number and types of the parameters are the same (except thatthe controlling parameter types may differ)
3. the number and types of the results are the same.
Thus, for every operation in T there must be a corresponding operationin S, though there may be more operations in Ops(S) than Ops(T). The specificationsof corresponding operations must match precisely (with the exception ofthe controlling argument).
The Core Object Model presents very strict typing rules that ensurethat substitutability9 can be guaranteedusing the information in the specifications. These rules can be relaxedsomewhat and still guarantee substitutability. One of the components definedin the OMG OM Components Guide describes a modified set of rules that loosenthe above conditions to allow argument and result types to differ but stillpreserve substitutability.
Editor's note: the OMG OM Components Guide exists in draft form only.
A single type can have multiple supertypes in the Core Object Model.The above typing rules, however, prevent two types that have an operationwith the same name but different signatures from having a common subtype.
Supertypes are used to characterize functionality that is common totheir subtypes. Often a supertype's interface is incomplete as a standalonetype. It relies on its subtypes to extend the interface. Other times, asupertype specifies a complete definition of some type, but the type isuseful only when it is combined with other types in a new subtype. In bothcases the supertype does not have any direct instances of its own. Onlysubtypes of this supertype can have direct instances. The Core Object modelrefers to these types as Abstract types.
4.2.6.2 Inheritance
Inheritance is a notational mechanism for defining a type S interms of another type T. The definition of S inherits all the operationsof T and may provide other operations. Intuitively, inherit means thatthe operations defined for T are also defined for or can be used by S10.
Subtyping is a relationship between interfaces (types). Inheritancecan apply to both interfaces and implementations; that is both interfacesand implementations can be inherited. The Core Object model is concernedwith inheritance of interfaces. It does not specify what can happen withimplementations of inherited operations (for example, whether they maybe changed or overridden by a subtype).
The Core Object Model relates subtyping and inheritance. If S is declaredto be a subtype of T, then S also inherits from T. The Core Object modelsupports multiple inheritance, which allows a subtype to have multiplesupertypes. The Core does not provide a name conflict resolution mechanismnor does it allow subtypes to redefine inherited operation signatures.These two constraints are relaxed in a component defined in the OMG OMComponents Guide.
Editor's note: the OMG OM Components Guide exists in draft form only.
Consider the following type definitions
type Person abstract supertypes: Object
operations: String social_security (P: Person) String name (P: Person)
end type
type Employee supertypes: Person
operations: Department dept (E: Employee) Money salary (E: Employee)
end type
In this example, type Employee is declared to be a subtype of type Person.In the Core Object Model this implies that
1. all instances of type Employee are also instances of type Person,and so an Employee object can be used wherever a Person object is expected.
2. Employee inherits the name and social_security operations from Person.
Furthermore, Person is declared to be an abstract type and so it cannothave any direct instances.
9 Substitutability means being able to substitutean object of some type S when an object of type T is expected, where Tis a supertype of S, while guaranteeing that that the substituted objectwill support the same operations as specified by the supertype T.
10 Whether Ops(S) is a superset of Ops(T) or thetwo are disjoint sets is an implementation issue and does not affect theCore semantics.
OMG CORBA IDL
CORBA supports interface inheritance, meaning that one interface canbe derived in terms of another. A derived interface may redefine any ofthe type, constant, and exception names which have been inherited. Multipleinheritance is supported in that an interface may be derived from a numberof base interfaces.
CORBA does not address object implementation inheritance.
ODMG
The model defines type inheritance only (i.e., subtyping). If S is asubtype of T, then S inherits all operations and properties of T, and Smay define new operations and properties applicable to its instances. Inother words, objects of type S have all the characteristics (and more)of type T. A subtype can specialize the properties and operations it inherits,but there are no rules given to indicate what kinds of refinement are correct.
A type can inherit from multiple supertypes, but must rename same-namedinherited operations or properties.
Section 2.2.1 notes that new subtypes may only be defined under typeObject. At this point (release 1.1) no subtyping is allowed for characteristictypes - attributes, type, relationships, operations. Type compatibilityfor objects is by name. Two objects have the same type if and only if theyare instances of the same named type. An object of a given type can beassigned to an object of any of its supertypes.
For literals, type compatibility is by structure - structured literals(immutable collections or structures) have the same type only if they havethe same structure at each level and corresponding atomic parts have thesame type. "Subtyping" of structured literals requires that bothhave the same structure at every level, and that the type of each 'subobject'of the supertype is the same or a subtype of the corresponding subobjectof the subtype (section 2.8.2.2 - contravariance).
EXPRESS
EXPRESS supports single as well as multiple inheritance (an entity typemay have more than one supertype). Attributes and constraints are inheritedfrom supertype to subtype entities. An instance of a subtype is valid inany context in which an instance of (any of) its supertype(s) is valid.
When a name conflict arises as a result of multiple inheritance, anyuse of the name in question must be prefixed with the name of the originallydefining entity type in order to provide an unambiguous reference.
In the case of repeat inheritance, where multiple inheritance causesa subtype to inherit from some supertype by more than one path, the subtypeinherits only one set of the attribute definitions from the supertype inquestion. If these attributes have been constrained differently along thedifferent inheritance paths, the subtype inherits all of the constraintsapplied along all of the paths.
Open Distributed Processing
Supports multiple inheritance of which single inheritance is a constraint.
The inheritance mechanisms are implementation dependent.
Two major forms of inheritance are possible:
a. Incremental inheritance - related to the class hierarchy, occurswhen a new class template is explicitly represented in terms of an existingtemplate.
b. Subtyping - related to the type hierarchy, occurs when a new classtemplate, together with the instantiation rules, produces a stronger predicatethan the old template with the (same) instantiation rules.
Management Information Model
The subclass inherits the operations, attributes, notifications, packagesand behavior of the superclass. This specification allows only for strictinheritance of characteristics... Specialization by deleting any of thesuperclass characteristics is not allowed. Multiple inheritance is theability of a subclass to be specialized from more than one superclass.The subclass inherits the operations, attributes, notifications, packagesand behavior from more than one superclass. When a class has multiply inheritedthe same characteristic from multiple superclasses, then that class isdefined as though that characteristic were inherited from only a singlesuperclass. Specialization shall not introduce contradictions in the subclass'sdefinitions. [Part 1]
SQL3
An ADT can be defined as a subtype of one or more ADTs by defining itas UNDER those ADTs (multiple inheritance is supported). In this case,the ADT is referred to as a direct subtype of the ADTs specifiedin the UNDER clause, and these ADTs are direct supertypes. A typecan have more than one subtype and more than one supertype. A subtype inheritsall the attributes and behavior of its supertypes; additional attributesand behavior can also be defined. An instance of a subtype is consideredan instance of all of its supertypes. An instance of a subtype can be usedwherever an instance of any of its supertypes is expected.
Every instance is associated with a "most specific type" thatcorresponds to the lowest subtype assigned to the instance. At any giventime, an instance must have exactly one most specific type (in some cases,multiple inheritance must be used to ensure this is true). The most specifictype of an instance need not be a leaf type in the type hierarchy. Forexample, a type hierarchy might consist of a maximal supertype person,with student and employeeas subtypes. student might have two directsubtypes undergrad and grad.An instance may be created with a most specific type of student,even though it is not a leaf type in the hierarchy. A TYPE predicate allowsfor the type of an ADT instance to be tested at run time.
A subtype definition has access to the representation of all of itsdirect supertypes (but only within the ADT definition that defines thesubtype of that supertype), but it has no access to the representationof its sibling types. Effectively, components of all direct supertype representationsare copied to the subtype's representation with the same name and datatype. To avoid name clashes, a subtype can rename selected components ofthe representation inherited from its direct supertypes.
A subtype can define operations like any other ADT. A subtype can alsodefine operations which have the same name as operations defined for othertypes, including its supertypes (overriding).
A table can be declared as a subtable of one or more supertables (itis then a direct subtable of these supertables), using an UNDERclause associated with the table definition. An example is:
CREATE TABLE person (name CHAR(20), sex CHAR(1), age INTEGER;
CREATE TABLE employee UNDER person (salary FLOAT);
CREATE TABLE customer UNDER person (account INTEGER);
The subtable facility is completely independent from the ADT subtypefacility. When a subtable is defined, the subtable inherits every columnfrom its supertables, and may also define columns of its own. A maximalsupertable (a supertable that is not a subtable of any other table) togetherwith all its subtables (direct and indirect) makes up a subtable family.A subtable family must always have exactly one maximal supertable. Anyrow of a subtable must correspond to exactly one row of each direct supertable.Any row of a supertable corresponds to at most one row of a direct subtable.
The rules for the SQL INSERT, DELETE, and UPDATE DML statements aredefined in such a way as to keep the rows in the tables of a subtable familyconsistent with each other, in accordance with the rules described above.Specifically:
The semantics maintained are those of "containment"; a rowin a subtable is effectively "contained" in its supertables.This means that, for example, a row could exist for a person in the persontable without a corresponding row in the employeetable (if the person is not also an employee). A row for a new employee,not corresponding to any existing person, could be inserted into the employeetable, and this would automatically create a corresponding row in the persontable.
Matisse
Matisse supports standard "specialization" inheritance asimplemented in C++ or Smalltalk and described in the Matisse entry under3. Binding.
Delegation can be implemented in Matisse by providing a method, trigger,or constraint, that invokes any other method(s) or function(s). In addition,there are "universal methods" that are independent of the inheritancehierarchy. These can be invoked by any method or function attached to thedatabase or from the application through the Matisse API.
C++
C++ supports multiple inheritance. Inheriting classes are called derivedclasses, and the classes they inherit from are called base classes.The derived classes inherit all the data members and member functions fromthe base class. The derived class may extend the base class by addingnew data members or member functions. The derived class may also overridemember functions from the base class by supplying a new definition forthe function.
There are two forms of derivation, public and private.When the declaration of a derived class contains the keyword publicpreceding the base class name, objects of the derived class can be treatedas if they were instances of the base class. In particular, an object ofthe derived class can be used to invoke member functions or access datamembers defined for the base class. If the publickeyword is omitted, then the class is privately derived by default, andobjects of the derived class cannot be used as if they were objects ofthe base class. For privately derived classes, only those data membersand member functions that are defined (or overridden) in the derived classcan be accessed. Member functions of a privately derived class can accessthe base class's data members and member functions, but users of objectsof the derived class cannot used the derived objects to access data membersand member functions of the base class. In other words, public inheritanceis used to define subtypes (which can also share behavior), while privateinheritance allows sharing of behavior, but does not permit an instanceof the derived class to be used in situations where a base class instancewould be expected.
For example, given a rectangle class [Wes90]:
class TRect { public: // data members short fTop; short fLeft; short fBottom; short fRight; // member functions virtual short Area(void); Boolean PointInRect(Point thePt); };a round cornered rectangle might be defined as:
class TRoundRect : public TRect { protected: // added data members short fHOval; short fVOval; // override the area member function virtual short Area(void); };A class may be derived from any number of base classes. The order ofderivation is not significant except possibly for default initializationby constructor, for cleanup, and for storage layout. The order in whichstorage is allocated for base classes is implementation dependent. Accessto base class members must be unambiguous. Ambiguities can be resolvedby qualifying a name with its class name [Str92].
OOCOBOL
The INHERITS clause of a class definition specifies the names of classesthat are inherited by the class being defined. A predefined CBL-BASE classis defined that COBOL classes can inherit from. Although it is not requiredthat classes inherit from CBL-BASE, this is the only way to write (in standardCOBOL) a creatable class. Class inheritance in OO COBOL is an implementationconcept. Interfaces can be defined that inherit the interfaces of classesand/or other interfaces. Multiple inheritance is supported for both classand interface inheritance. Rules are defined to insure that implementationinheritance implies interface conformance, even in cases of multiple inheritance.The collection of class and interface definitions effectively form a singlesubtype hierarchy defined by the conformance relationships between theobject, class object, and interface definitions.
See also entry under 7. Types and Classes.
Smalltalk
Smalltalk class relationships are defined in terms of inheritance. Theproperties of one class are be inherited from another class in a hierarchicalstructure beginning with the upper-most class (Object). In inheritance,the inheriting class is called the subclass and the class being inheritedfrom is call the superclass. A subclass inherits all of its superclass'variables and methods.
Abstract classes are classes from which other classes are inherited(subclassed) only. Instances can be implemented any non-abstract class.
Subclasses are specialization of their superclasses. A subclass mayadd variables, but it cannot delete those inherited from the superclass.A subclass may accept an inherited method or it may override the methodby providing an new method with the same name (or message selector).
Object instances are instances of a class. Smalltalk does not providefor delegation (defined as object instances being created from other objectinstances and not a class).
Eiffel
Eiffel uses a multiple inheritance model. Subclasses may inherit fromone or more superclasses. A class may also inherit from one class manytimes. This is repeated inheritance.
Inheritance in Eiffel is used both as a module extension mechanism anda type refinement mechanism.
The problems of name clashes and conflicts caused by multiple inheritancecan be alleviated using a number of `feature_adaptation' clauses. The propertiesof inherited features can be modified in the following ways:
renaming -- to remove any name clashes, and also to provide contextspecific
names to features.
exporting -- changing the export status of features. By default theexport status of
inherited features is the same as in the parent. The export status canbe
changed.
undefining -- Changing an operation with an implementation to an operation
without an implementation. From `effected' to deferred'.
redefining -- Modifying the signature and implementation of an operation.The
signature, preconditions and postconditions must conform to the original
definition.
selecting -- Removing conflicts for dynamic binding under repeated inheritance
sharing -- merging two (or more) features from a repeatedly inheritedclass into
one feature.
joining -- merging two deferred features (with compatible signatures)into one.
Emerald
Emerald supports type conformity (and hence object substitution), butit does not support (implementation) inheritance. Code cannot be explicitlyshared among object implementations (see the entry under 7. Types andClasses). The absence of code sharing is due to Emerald's use in distributedsystems; the mobility of an object is enhanced when it is self-contained,and hampered if it is dependent on other objects. Emerald allows differentimplementations to be used for the same abstract type within a single program.[RTLB+91]
Cecil
Cecil uses a classless (prototype-based) object model, hence objectscan inherit directly from other objects to share code. Inheritance maybe multiple, by listing more than one parent object. Like most object-orientedlanguages, in Cecil the inheritance graph is static. An object cannot changeits ancestry after it has been created. These restrictions preclude someflexibility traditionally associated with prototype-based languages, suchas dynamic inheritance in SELF, but simplify type checking. The inheritancestructure of an object may be augmented after the object is created throughan object extension declaration (see entry under 10.1 Dynamic).Inheritance in Cecil requires a child to accept all of the fields and methodsdefined in the parents. These may be overridden in the child, but facilitiessuch as excluding fields or methods from the parents or renaming them aspart of the inheritance are not available in Cecil.
In Cecil, inheritance of code is distinct from subtyping (inheritanceof interface or specification). Use of the type keywordin an object definition declares that the object also specifies a type(a set of method signatures), and subtypes declarationsseparate from the inherits declarations describe anobject's relationship to types in the subtype lattice. This distinctionenables an object to be a subtype of another without being forced to inheritany code, and enables an object to inherit code without being restrictedto be a legal subtype of the parent object (see entry under 7. Typesand Classes). [Cha92]
SELF
SELF supports implicit delegation [CMC92]. This means that whenan object cannot answer a message, the interpreter automatically delegatesit to another object (as opposed to explicit delegation, in whichdelegation is specified explicitly for each message to be delegated). InSELF, the object to which an object delegates a message is called the object'sparent. Objects have parent slots to inform the interpreter to whichobjects messages should be delegated.
System Object Model (SOM)
A class defines both an interface and an implementation for objects.The interface defines the signature of the methods supported by objectsof the class, and the implementation defines what instance variables implementthe object's state and what procedures implement its methods.
New classes are derived by sub-classing from previously existing classesthrough inheritance and specialization. Subclasses inherit their interfacesand implementations from their parent classes unless they are overridden.
SOM supports multiple inheritance. That is, a class may be derived frommultiple parent classes.
OLE Component Object Model
Windows Objects and the classes they identify through class identifiershave no notion of implementation inheritance. One Windows Object does notinherit the implementation of another Windows Object. Instead, reuse ofobjects is supported through the containment and aggregationmechanisms. In the Component Object Model, inheritance is simply consideredas a language-specific tool (e.g., in C++) that may be useful for implementingclasses and defining interfaces in that language. The reason given fornot supporting inheritance is that systems built on it must ship all theirsource code in order to be useful [Bro94a]. For example, inheritance cannotbe used to inherit from objects used in the operating system itself, forwhich source code is not available.
In the Component Object Model, both the containment and aggregationmechanisms work by using the implementation of another object. However,the object being used remains entirely self-contained and operates on itsown instance of data. The containing object also works on its own data,and calls the other object as necessary to perform specific functions forwhich it can be passed the data on which to operate.
To implement what corresponds to a subclass Y of a class X using containment,class Y completely contains an X object and implements its own versionof the X interface which it exports to clients. This makes Y a simple userof X, and X need not know about its use within Y. This is useful when Yneeds to override some aspect of X's behavior. Since all external callsgo to the Y implementation first, Y can either override selected behavioror pass the calls directly through to X.
To implement what corresponds to a subclass Y of a class X using aggregation,class Y directly exposes X's interface. This requires that X "know"that its interface is exposed for something other than itself, such thatthe QueryInterface, AddRef, and Release functionsbehave as a user expects (e.g., X's QueryInterface function mustbe capable of returning references to interfaces implemented by Y which,as a part of an X interface, it did not originally know about; OLE providesa mechanism for dealing with this when an aggregate is created).
Windows Objects do support a specific case of interface inheritance,in that all other interfaces derive from IUnknown, as describedin the entry under 2. Objects. Generally, however, unlike modelssupporting a "conventional" subtyping mechanism for objects havinga single interface, the interfaces in Windows Objects remain distinct.Through a pointer to a Y interface, the object cannot be treated as anX, even if the object also has an X interface; instead, the user must explicitlyget a pointer to the X interface.
C++ multiple inheritance is a convenient way to provide multiple functiontables for each interface, since the compiler generates them automatically.Because each implementation of a C++ member function is already part ofthe object class, each automatically has access to everything in the object.[Bro94a] also discusses a more general approach to constructing objects,for use by programmers in C and other languages that do not provide built-ininheritance. In this approach, a C++ object class corresponding to theWindows Object class inherits from IUnknown, and implements thesefunctions to control the object as a whole. Each interface supported bythe object is then implemented in a separate C++ class that singly inheritsfrom the interface it is implementing. These "interface implementations"are instantiated with the object, and live as long as the object lives.The IUnknown members of these interface implementations always delegateto some other IUnknown implementation, which in most cases is theoverall object's IUnknown. Each interface implementation also holdsa "back pointer" to the object in which the implementations arecontained so that they are able to access information centrally storedin the object. In C++, this generally requires that each interface implementationclass be a friend of the object class.
Analysis and Design Methods
SA: Multiple inheritance is used in datamodeling. No explicit concept of delegation.
CA: Inheritance may be single or multiple.The terms used are 'hierarchy generalization-specification structure' and'lattice generalization-specification structure.' No explicit concept ofdelegation.
RA: "Inheritance is a mechanismfor implementing generalization, in which the behavior of a superclassis shared by all its subclasses. Sharing of behavior is justifiable onlywhen a true generalization relationship occurs, that is, only when it canbe said that the subclass is a form of the superclass."
"Delegation consists of catchingan operation on one object and sending it to another object that is partof o r related to the first object."
JA: Inheritance: "The descendenthas all of the properties of the ancestor. ...the descendant knows of itsancestor, but the ancestor does not know of its descendants.
Extends: "One object extends anotherobject" by providing additional functionality. This concept correspondsto 'delegation.'
Jacobson et al. refer to delegation asreuse of code through composition, rather than inheritance.
WD: "Collaborations represent requestsfrom a client to a server in fulfillment of a client responsibility. Acollaboration is the embodiment of the contract between a client and aserver. An object can fulfill a particular responsibility itself, or itmay require the assistance of other objects. We say that an object collaborateswith another if, to fulfill a responsibility, it needs to send the otherobjet any messages."
"... [S]ubsystems delegate eachcontract to a class within them that actually supports the contract."
MD: "(Inheritance): A class maybe defined as an extension or restriction of another.
"...[I]f types are identified withmodules, then it is tempting to identify the reusability mechanisms providedby both concepts: On the one hand, the possibility for a module to directlyrely on entities defined in another. On the other hand, the concept ofsubtype, whereby a new type may be defined by adding new properties toan existing type. In object-based languages, this is know as the inheritancemechanism, with which a class may be defined as an extension or restrictionof a previously defined one."
EA: '... [T]he essential idea for isa relationships sets is that one object class is a subset/superset of another.""A superset object class is called a generalization, and a subsetobject class is called a specialization." "Since the membersof a specialization are also members of a generalization, they all participatein the relationship sets of a generalization. The converse, however, doesnot hold because some members of a generalization may not be members ofa specialization, and may, therefore, not participate in the relationshipsets of the specialization. This observation leads to the notion of inheritance.""A specialization inherits the relationship sets of its generalization."There are no attributes in the model.
"... [W]e have multiple inheritancewhen a class is a specialization of two or more generalizations."
FA: "In a generalization, the attributesand relationships of the supertype are 'inherited' by the subtypes. Eachsubtype may have additional attributes and participate in additional relationships.Specialization is the converse case in which a new subtype is defined asa more specialized version of a supertype."
"During analysis, abstract subtyperelationships between classes are identified. Specialization defines asemantic relationship between tow classes: the general and specific ones.This semantic relationship is inherent in the domain of the system. Specializationand generalization are properties of the domain model and not of the systemdesign or implementation."
"Multiple specialization allowsa new subtype to be defined as a specialization of more than one immediatesupertype. ... The subclass inherits the attributes and relationships ofall its superclasses."
FD: "At design ... the inheritancerelationship is a property of the system and not necessarily of the domain."
"... [C]ollaborators collaborateand cooperate with the controller to implement the system operation."
OA: "...[T]he word inheritance hasnot been used in conjunction with generalization. In OO analysis, thisterm is not appropriate ... to refer to the application of a type's propertiesto its subtypes. It is appropriate, however, for OO design. In OO programming,inheritance is the mechanism that facilitates the reuse of program codefrom a class to its subclasses."
BD: "... [I] defines a relationshipamong classes, wherein one class shares the structure or behavior definedin one or more classes (denoting single inheritance and multiple inheritance,respectively).
"An alternative approach to inheritanceinvolves a language mechanism called delegation, in which objects are viewedas prototypes (also called exemplars) that delegate their behavior to relatedobjects, thus eliminating the need for classes."
HA: Delegation: "Contracting withan O/C to provide a service places a responsibility on that O/C... However,it is of no interest to the client whether the supplier fulfills its contractitself or by subcontracting to one or more other classes.
Generalization/specialization (or specializationinheritance) represents the is-a-kind-of relationship. Specification inheritancepermits polymorphic substitutability but not necessary specialization inheritance.Implementation inheritance "focuses on code inheritance, rather thanon behavior and substitutability". Multiple generalization and multipleinheritance are both allowed.
NA: "A class may inherit from oneclass (single inheritance), from several classes (multiple inheritance),or several times from the same class (repeated inheritance). Inheritanceis simply defined as the inclusion in a class ... of operations and contractelements defined in other classes ..." "Delegation[:] Refersto shared behavior in object-oriented systems using prototypes insteadof classes ..." as in the language, Self. [See Self entry--ed.]
features matrixintro page