Implementation inheritance (object-oriented programming)
Encyclopedia : I : IM : IMP : Implementation inheritance (object-oriented programming)
Implementation Inheritance (II) is a special form of inheritance in object-oriented languages.
It allows children of the same parent to share code implemented in the parent.
By using Implementation Inheritance any replicated functionality, among the children, is aggregated to the parent (functional aggregation), and then shared along the lines of inheritance between parent and child (ancestor/descendent).
General
Implementation Inheritance (II) is a fundamental feature of most object-oriented languages. Implementation Inheritance allows a child (the derived class) to USE code elements in the parent (the base class). Methods, variables and other code elements are said to be 'implemented' in the parent and 'accessible' to the child.
A common use of Implementation Inheritance is when a child uses a method defined in the parent. In this case the parent will 'do the work' (perform some function) when called upon by the child. Any other child that inherits from that parent can re-use the same method.
From a software design point of view this code-reuse allows common functionality in the codebase to migrate (gravitate) to base classes where it can be shared along the lines of inheritance from the parents. The result is a 'functional aggregation' of common code to the parents.
Specification Vs. Implementation
Implementation Inheritance (II) is an aspect of class inheritance and is generally contrasted to Virtual Inheritance (VI).
In Implementation Inheritance an inherited child method inherits the FULL IMPLEMENTATION of the method defined in the parent. Thus the child can USE the FUNCTIONALITY defined in the parent. As such the parent SHARES an IMPLEMENTATION of the functionality with every child. This 'sharing' leads to code reuse within the 'functional structure' (inheritance graph) of the class hierarchy created by class inheritance.
Virtual Inheritance, on the other hand, FORCES an IMPLEMENTATION requirement on the child. This leads to the ability of the parent to delegate functionality to the child. The different functionality in different children can then be controlled by the parent in an identical manner
Default Virtual Methods
Implementation Inheritance (II) is defined as sharing code within a class hierarchy via the lines of inheritance between parents and their children (ancestors and descendents).
It is important to note that language specific SYNTACTIC EXPRESSIONS of Virtual Inheritance (VI) (in SOME languages) makes use of Implementation Inheritance when the SPECIFIC LANGUAGE SYNTAX provides a 'default implementation' of a code element (in the output of the language compiler).
A case in point is when a parent defines a Default Virtual Method. A child then has an option to use the 'default method' OR it can implement is own version of the method (which must have the same method signature.
Default Virtual Methods can be initially confusing when first encountered because they exist in the context of Virtual Inheritance while providing shared functionality (from parent to child) via Implementation Inheritance.
It is important to note, therefore, that Default Virtual Methods are the point where Implementation Inheritance overlaps Virtual Inheritance. As such Default Virtual Methods provide flexibility in software design articulated by the 'option' the child can exercise in implementing a virtual method.
Note that a child can elect to implement a virtual method and still call the default virtual method of the parent (within the body of its version of the virtual method). In this case Implementation Inheritance is used in conjunction with Virtual Inheritance to implement the virtual method of the child.
Single (SII) Vs. Multiple Implementation Inheritance (MII)
Single Implementation Inheritance (SII) refers to a feature of object-oriented programming languages in which a class can inherit behaviors and features from ONLY ONE parent. In this case common code in the children can be migrated and shared to only one parent (functional stratification WITH NO FUNCTIONAL ORTHOGONALITY). If the common code is orthogonal (see below) the resulting 'inheritance LINE' allows ONLY 'functional stratification' (layers of inheritance) of the computing functionality
Multiple Implementation Inheritance (MII), on the other hand, refers to a feature of object-oriented programming languages in which a class can inherit behaviors and features from MORE THAN ONE parent. In this case common code can be migrated, along functionally orthogonal lines, to many parents (functional stratification WITH FUNCTIONAL ORTHOGONALITY). If the common code is functionally orthogonal (see below) the resulting 'inheritance TREE' allows BOTH 'orthogonal partitioning' (within a single layer of inheritance) AND 'functional stratification' (layers of inheritance) of computing functionality.
With Single Implementation Inheritance there is no inheritance mechanism to separate the common functionally in a child into separate 'functionally orthogonal' parents.
Orthogonal Functionality
When functionality is naturally independent it is said to be 'orthogonal functionality'.
For example, three main areas of common computing functionality are presentation, messaging and storage.
Each of these functional areas are orthogonal in their natures. Storage, for example, can take place without presentation or messaging. Each functional area is considered independent and self sufficient. Each is also considered a 'platform' to be used in the composition of a software application. Each is commonly stratified into more than one layer.
In general the implementation of orthogonal functionality should be grouped along orthogonal lines. This design intention is the key impetus for Multiple Implementation Inheritance.
Functional Delegation Vs. Functional Aggregation
Implementation Inheritance (II) has functional aggregation, distribution and code re-use aspects to its semantics.
In the context of software design, Implementation Inheritance (II) is a 'functional aggregation' mechanism (Vs. Object Aggregation - referential containment) that allows children to use functionality implemented (aggregated) IN the parent.
Implementation Inheritance (II) 'aggregates' functionality to a single location (the IMPLEMENTATION in the parent) and 'distributes' that functionality along the (parent/child) lines of inheritance.
Virtual Inheritance, on the other hand, is a control mechanism for parents that allows 'functional delegation' via an implementation IN the child.
Within the context of class inheritance, functional aggregation and functional delegation SPECIFY where the IMPLEMENTATION of the functionality will reside. FUNCTIONAL DELEGATION specifies that POLYMORPHIC functionality will reside among the children. FUNCTIONAL AGGREGATION specifies that COMMON functionality, needed by the children, will reside in the parents.
Object-Oriented Functional Normalization
In languages that support Multiple Inheritance of Implementation (MII) the functional aggregation of replicated code (code migration to parents) is called 'Functional Normalization'. Functional normalization simplifies the codebase by removing needlessly replicated code and centralizing functionality into one location. This functionality is then made accessible (distributed) via the lines of inheritance.
Thus Functional Normalization is the process of factoring out replicated code. In this process common code 'migrates' TO the base classes (Vs. migration TO the derived classes).
In object-oriented languages Functional Normalization is not possible without Multiple Inheritance of Implementation. This is because the functional structure of encapsulation, formed by inheritance in the class hierarchy, can only distribute its encapsulated functionality via inheritance (which is a definitive aspect of object oriented languages).
When functionality migrates along orthogonal lines (different parents) only Multiple Inheritance of Implementation can bring that functionality back to the child as an inherited function. Since 'COMMON CODE MIGRATION' is ultimately 'ORTHOGONAL' in its nature (there is no Single-Super-Class that does everything), orthogonal functional migration REQUIRES multiple parents.
Single inheritance (SI), on the other hand, can only inherit from one parent. Non-orthogonal normalization is possible (migration of common code from child to parent) but only to a single parent. Orthogonal Functional Migration of common code (in a large code base) to many orthogonal parents is not possible with single inheritance as there is NO (object-oriented inheritance specific) Normalization Mechanism.
Thus Multiple Implementation Inheritance is the normalization mechanism in object-oriented languages.
See also
- Functional normalization (object-oriented programming)
- Virtual Inheritance (object-oriented programming)
From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.