Virtual inheritance

It is important to understand the difference in the use context of virtual code elements (GVI Vs. SVI). The use context determines who can use the virtual control mechanism formed via the inherited virtual code element specification. The 'use context' determines if the parents can directly use the virtual code elements or not.

The sections below highlight the core aspects of virtual inheritance as it exists in the C# language.

C# Method Override Ambiguity (MOA)

C# uses virtual inheritance the same way C++ does for method overriding. Differing from C++, C# requires the keyword override modifier to produce a fixed behaviour in the derived class (fixed object Vs. castable object - see below).

Normal method overriding is limited to the context of the object's current casting.

For Example:

using System;
//
public  class Human

}

public  class Mutant : Human

}

public  class Test_driver

}

// Test_driver output
//
// WITH     -  'override' keyword for Mutant : Output is 'Fixed'
//
// Eye color is : Yellow
// Eye color is : Blue
// Eye color is : Yellow
//
// WITHOUT  -  'override' keyword for Mutant : Output is 'Castable'
//
// Eye color is : Yellow
// Eye color is : Blue
// Eye color is : Blue
//

The Human Impersonator output compares fixed to castable behaviour.

In the case where the design intention supports impersonation, the castable design having MOA is preferred over the fixed design without MOA. The example shows that MOA is NOT an inherent problem in design architectures.

The 'impersonation' above is a good example of the desirable functionality of MOA. Real world examples of impersonation are evident in high security systems where security proxies will be used to 'impersonate' clients for access requests. In this design context security proxies improve the overall performance, implementation and maintainability of such systems.

MOA in any language is only a problem if the program architecture was not designed correctly. Having behaviour implemented as a castable object or a fixed object is dependent upon the design intentions of a good software architecture.

Simple Virtual Inheritance (SVI) via Interface Inheritance

General Virtual Inheritance (GVI) has two primary criterion for its architecture.

• (1) Virtual Control Mechanism (VCM)
• (2) Direct Parental Use of the VCM (parental use context)

The second GVI criterion is that the direct parental use context allows the 'parent' to 'use' the code elements (in the child specification) as if the implementation (of the code elements) were its own.

Interface Inheritance, on the other hand, also has two primary criterion for its architecture

• (1) Virtual Control Mechanism (VCM)
• (2) Client Use of the VCM (client use context)

The second Interface criterion is that Interfaces become a 'type' unto themselves which allows ANY client of that type to access and 'control' (call, assign, etc) the code elements defined in the specification of the interface.

The advantage with Interfaces is that the Virtual Control Mechanism (VCM) has its own type. Another advantage is that the 'type' is a set of code elements. A disadvantage of interfaces is that the virtual code elements ARE NOT usable by the parent (as they are in GVI).

Thus Interfaces allow for a 'Simple Virtual Inheritance' (SVI not GVI) of the specification that does not allow direct parental use of the virtual control mechanism. Interface usage is open to all clients of the interface as a new object type. In effect the Interface is a contract specifcation that separates what an object (interface instance) does from how it does it.

Both GVI and interfaces (SVI) use 'virtual inheritance' to specify a control mechanism for code elements (specifications via inheritance). They differ however in WHO is going to use the Virtual Control Mechanism. With GVI its the parents who use the code elements. With Interfaces its everyone else who uses the code elements (which MAY be a 'parent-as-client').

GVI provides parents a 'virtual' code element. Interfaces (SVI) provide client objects a 'virtual' set of code elements (contained in the interface implementation).

Use Context of Virtual Code Elements

The Subject Interface example below shows Virtual Inheritance (VI) in the context of Interface Inheritance. It demonstrates the Virtual Control Mechanism (VCM) aspect of Interfaces (SVI). It shows that virtual control mechanisms can contain assignable state space (in addition to callable code elements like methods). Finally it shows the client use context of the VCM specified by the Interface.

using System;
//
// Subject Interface Example
//
//#------------------------------------------------------------------------------------------------#
//#   Binding Mechanism :_:   Delegate for event binding between subject and observer
//#                           Use_SVI(4) an Interface event shows a loadable virtual control element
//#------------------------------------------------------------------------------------------------#
public   delegate    void     Delegate_signature( string p_notification_message );

//#------------------------------------------------------------------------------------------------#
//#   Pattern Manager   :_:   Binds the observer to the subject and fires subject events
//#------------------------------------------------------------------------------------------------#
class Observer_manager

}
//#------------------------------------------------------------------------------------------------#
//#   Subject Binder    :_:   Binds the manager to a preexistent subject defined outside the manager
//#                           Use object composition for external pattern participants
//#------------------------------------------------------------------------------------------------#
//
public Observer_manager( Subject_API_surface p_subject )

//
//#------------------------------------------------------------------------------------------------#
//#   Pattern Driver    :_:   Creates pattern participants, binds participants, fires subject events
//#                           Use object aggregation for internal pattern participants
//#                           Use_SVI(2) to drive different subjects via the Contract aspect of VCM
//#------------------------------------------------------------------------------------------------#
public
void  Main_process()

}

//#------------------------------------------------------------------------------------------------#
//#   Subject_A         :_:   Contains events that notify any observers (notification targets)
//#                           Use_SVI(3) do not have a notification count for this subject type
//#------------------------------------------------------------------------------------------------#
class Subject_A : Observer_manager.Subject_API_surface

bool     notification_gate_flag;
//
public   bool     Fire_event( string p_event_identity )

//
public   event    Delegate_signature   notification_targets;
//
public   bool     Notification_gate_flag

set

}
}

//#------------------------------------------------------------------------------------------------#
//#   Subject_B         :_:   Contains events that notify any observers (notification targets)
//#                           Use_SVI(3) have a notification count for this subject type
//#------------------------------------------------------------------------------------------------#
class Subject_B : Observer_manager.Subject_API_surface

bool     notification_gate_flag;
//
public   bool     Fire_event( string p_event_identity )

//
public   event    Delegate_signature   notification_targets;
//
public   bool     Notification_gate_flag

set

}
}

//#------------------------------------------------------------------------------------------------#
//#   Observer          :_:   A 'notification target' - waits for notification - prints notification
//#------------------------------------------------------------------------------------------------#
public class Observer

//
public void Notify_me(string  p_notification_message )
 : Notification message -  ",
my_identity,
p_notification_message
);
}
}  // End_of_class

//#------------------------------------------------------------------------------------------------#
//#   Test Driver       :_:   Main entry point for console application - Creates, runs binder/manager
//#------------------------------------------------------------------------------------------------#
class Test_driver

}

//#------------------------------------------------------------------------------------------------#
//#   Output            :_:   Show pattern binding via interface contract specification
//#
//#   Conceptual aspect  1    Show_SVI(1) as a 'client use context' VCM (manager VCM for subject)
//#   Conceptual aspect  2    Show_SVI(2) contract aspect, driving different type objects (Subject A,B)
//#   Conceptual aspect  3    Show_SVI(3) contract does not specify behaviour (polymorphic output A,B)
//#   Conceptual aspect  4    Show_SVI(4) virtual code elements are 'controllable'
//#------------------------------------------------------------------------------------------------#
//
//    Observer Instance Number One : Notification message - Notification : System A : Event_1
//    Observer Instance Number Two : Notification message - Notification : System A : Event_1
//    Observer Instance Number One : Notification message - Notification : System A : Event_3
//    Observer Instance Number Two : Notification message - Notification : System A : Event_3
//
//    Observer Instance Number One : Notification message - Notification 1 : System B : Event_1
//    Observer Instance Number Two : Notification message - Notification 1 : System B : Event_1
//    Observer Instance Number One : Notification message - Notification 2 : System B : Event_3
//    Observer Instance Number Two : Notification message - Notification 2 : System B : Event_3
//

Virtual Control Mechanism (VCM) : The Subject_API_surface interface defines the set of virtual code elements needed by the manager to control the subject. The specification, via the Interface, forces the child to implement the code elements it defines. The elements are 'virtual' because they are controlled through the specification (not an implementation) defined by the interface.

The VCM allows different types of objects to be controlled by the same set of virtual code elements. Any class that inherits the Interface will be forced to provide the set of 'implementation code elements' represented by the virtual code elements. The Observer_Manager class displays this capability by being able to control the Subject_A and Subject_B object types (classes).

Assignable State Space : In the example above the Main_process of the Observer_manager contains the Notification_gate_flag code element which is an assignable code element (single value assignment). The notification_targets code element is a loadable code element (multi-value assignment).

In Virtual Inheritance code elements are said to be 'controllable'. This means that a code element can be called (method), assigned (bool) or loaded (event). The conceptual semantics of the 'control aspect' do not, and should not, address the implementation details of a particular compiler or language. This control aspect is an important difference between virtual inheritance and virtual functions (VTables - compiler implementation).

Client Use Context : Note that virtual code elements, established via inheritance (in C#, C++, java or any language), ALWAYS have a use context aspect. The use context aspect determines how the specification can be leveraged in the software design architecture.

For example, can the parents leverage the code elements for polymorphic control (GVI)? Can client objects leverage the 'interface aspect' and drive a target object via the 'interface' without a concern about other 'aspects' of the object (SVI - contract aspect as in the code above)?

The Subject Interface code shows that Simple Virtual Inheritance (SVI) has a client use context aspect to its conceptual semantics. In GVI the parents have control. In SVI everyone, except the parents, has control.

Object-oriented languages may feature other use contexts for virtual code elements besides parent/client (GVI/SVI). Thus it is important to note that Virtual Inheritance (VI) is centric first to the specification aspect (VI) and then to the use context aspect (GVI/SVI/etc).

Stateful Diamond Point (SDP) Pattern in C#

Understanding the use context of virtual code elements is important in understanding the design advantages and disadvantages of virtual inheritance. The Stateful Diamond Point pattern (presented in the C++ section) is implemented in the C# language below. It shows the coexistence of General and Simple virtual inheritance (GVI and SVI).

In C# the same pattern participants exist but are connected using Single Implementation Inheritance (SII) and object aggregation. Virtual inheritance (VI), in the context of the C# design approach (GVI/SII), can be compared to VI in the C++ design approach using functional normalization, aggregation and dispersion along the lines of inheritance (GVI/MII). The comparison shows how VI (GVI/SVI) effects the internal functionality of the SPD pattern.

In the C# SPD pattern implementation the core design concern is still the functionality (the Point of the design) presented by the surface API at the Execution Point. With C# Interfaces the pattern surface API can be formalized as the execution point interface.

The SPD pattern in C# has the same 'Arrow' data flow pattern as found in the C++ example. In the C# example the data flows;

1. From the (1) execution point (interface surface) to the (2) foundation (via SII)
2. From the (2) foundation to the (3) execution point (via GVI)
3. From the (3) execution point to the (4,5) support classes (via object aggregation)

1. From the (1) execution point (interface surface) to the (2) foundation (via MII)
2. From the (2) foundation to the (3) execution point (via GVI)
3. From the (3) execution point to the (4,5) support classes (via MII)

The High State Tracker example of the SPD pattern is more reflective of real world production software (then the shorter C# examples herein). It features the following C# Virtual Inheritance phenomena (GVI/SVI-Interfaces).

High State Tracker Example - Code Features

Code Feature	Implementation Description
Coexistence	GVI, SVI, Interfaces, object aggregation (embedded members)
GVI Control mechanism	Virtual method specification - Base::Log_state()
GVI Implementation	Virtual method implementation - Diamond_tracker::Log_state()
SVI Specification	Interface inheritance - Execution_point_interface
SVI Parent	Test_driver::Execution_point_interface
SVI Child	Diamond_tracker
Execution Point Contract	C# Interface for the surface API of the SPD pattern used by the test driver
Object Aggregation	Via embedded members Internet_child, Database_child
Aggregate Construction	Construction code for Internet_child, Database_child
Surface API Replication	Diamond_tracker must replicate Get_local_highest_state(), Get_global_highest_state() API surface

The C# and C++ examples help to distinguish the concepts;

• Functional normalization/dispersion/aggregation along lines of inheritance (GVI/MII)
• Object aggregation and interface specification (GVI/SII)

Relative to Virtual Inheritance (GVI/SVI) the C# implementation of the SPD pattern differs from the C++ implementation in several important ways. A comparative examination of the code reveals these differences stem from the difference between GVI/MII and GVI/SII. This difference is relevant to SVI and its role in pattern functionality.

It is important to note that the Interface SVI adds nothing to the functionality of the pattern itself. Thus SVI is not responsible for the key differences in the two designs (C++ Vs. C#). This highlights the contractual mechanism aspect of SVI in Interfaces brought about by the virtual code element use context (as explained above). It also allows SVI to be factored out in any functional partitioning design issues (as explained below).

Coexistence of Virtual and Interface Inheritance in C#

The coexistence of Virtual Inheritance (GVI) and Interfaces (SVI) in C# is demonstrated in the High State Tracker example code presented below. The code is basically a port to C# from the C++ example (above).

Since C# lacks Multiple Implementation Inheritance (MII) the design of the C# code uses Single Implementation Inheritance and object aggregation. The functionality (the output) of the SPD pattern C# implementation is identical to the C++ example.

using System;
//
// High_State_Tracker Example
//
//#------------------------------------------------------------------------------------------------#
//#   State machine     :_:   Manages state space - Ties all concerns together
//#                           Use GVI - Specify Child 'Log_State()' and use it as Virtual Method
//#------------------------------------------------------------------------------------------------#
internal abstract
class Base

//
protected void Set_state(int next_state)
 ", Current_state  );
Log_state( Current_state ); // Use GVI : Control children and keep history of state changes
}
//
public   int   Get_current_state()

//
public   abstract                    // Virtual Method (Shows GVI - General Virtual Inheritance)
void  Log_state(int new_state);   // Specify here : Instantiate in Diamond class
} // End of class

//#------------------------------------------------------------------------------------------------#
//#   Global Manager    :_:   Logs high states to global office - manages global concerns
//#                           Use object aggregation to incorporate functionality in SII child class
//#------------------------------------------------------------------------------------------------#
class Internet_child

//
public   void  Log_global_high_value(int new_state)

}
//
public   Internet_child()                       // Internet retrieval could go here

//
public   int   Get_global_highest_state()

} // End of class

//#------------------------------------------------------------------------------------------------#
//#   Local Manager     :_:   Logs high states to local home office - manages local concerns
//#                           Use object aggregation to incorporate functionality in SII child class
//#------------------------------------------------------------------------------------------------#
class Database_child

//
public   void  Log_local_high_value(int new_state)

}
//
public   Database_child()                       // Database retrieval could go here

//
public   int   Get_local_highest_state()

};

//#------------------------------------------------------------------------------------------------#
//#   Session Manager   :_:   Tracks high states in the current session - manages immediate concerns
//#                           Use GVI - Parent (Base) controls child (Diamond_tracker::Log_state())
//#                           Use SVI - Force child to implement surface API needed by test driver (Test_API_surface)
//#                           Use object aggregation to bring in local and global manager functionality
//#------------------------------------------------------------------------------------------------#
class Diamond_tracker : Base,  Test_driver.Execution_point_interface

//
public   Diamond_tracker()

//
public   void  New_state(int new_value)

Set_state( new_value );               // Move system to new state via Base
}
//
public   int   Get_session_highest_state()

//
public   int   Get_local_highest_state()

//
public   int   Get_global_highest_state()

};

//#------------------------------------------------------------------------------------------------#
//#   Test Driver       :_:   Drives the high state tracker (Diamond_Tracker)
//#                           Show SVI as execution point contract via the C# Interface
//#------------------------------------------------------------------------------------------------#
class Test_driver

//
public static void Main()
 ", parent_as_client_API.Get_session_highest_state() );
Console.WriteLine(" Start    :  Highest local   state is :  ", parent_as_client_API.Get_local_highest_state() );
Console.WriteLine(" Start    :  Highest global  state is :  ", parent_as_client_API.Get_global_highest_state() );
Console.WriteLine();
//
my_diamond.New_state( 10 );
my_diamond.New_state( 30 );                  // Highest local state at start
my_diamond.New_state( 40 );
//
Console.WriteLine();
Console.WriteLine(" End      :  Highest session state is :  ", my_diamond.Get_session_highest_state() );
Console.WriteLine(" Middle   :  Highest local   state is :  ", my_diamond.Get_local_highest_state() );
Console.WriteLine(" Middle   :  Highest global  state is :  ", my_diamond.Get_global_highest_state() );
Console.WriteLine();
//
my_diamond.New_state( 70 );                  // Highest global state at start
my_diamond.New_state( 10 );
my_diamond.New_state( 80 );
//
Console.WriteLine();
Console.WriteLine(" End      :  Highest session state is :  ", parent_as_client_API.Get_session_highest_state() );
Console.WriteLine(" End      :  Highest local   state is :  ", parent_as_client_API.Get_local_highest_state() );
Console.WriteLine(" End      :  Highest global  state is :  ", parent_as_client_API.Get_global_highest_state() );
Console.WriteLine();
}
}  // End_of_class

//#------------------------------------------------------------------------------------------------#
//#   Output            :_:   Show the state transitions - Highest state logged locally and globally
//#                           Show GVI as an internal pattern unit mechanism - Parent use context
//#                           Show SVI as an external pattern unit mechanism - Client use context
//#------------------------------------------------------------------------------------------------#
//
//    Start    :  Highest session state is : 0
//    Start    :  Highest local   state is : 30
//    Start    :  Highest global  state is : 70
//
//             :          Current state is - 10
//             :          Current state is - 30
//             :          Current state is - 40
//
//    Middle   :  Highest session state is : 40
//    Middle   :  Highest local   state is : 40
//    Middle   :  Highest global  state is : 70
//
//             :          Current state is - 70
//             :          Current state is - 10
//             :          Current state is - 80
//
//    End      :  Highest session state is : 80
//    End      :  Highest local   state is : 80
//    End      :  Highest global  state is : 80
//

SVI Parent : Note that the contract (Execution_point_interface) is in the namespace of the test driver. Syntactically the contract is the parent, not the test driver. Conceptually, however, the interface is a specification mechanism in the design architecture that binds the test driver to the target (Diamond_tracer). This design architecture is named 'parent-as-client' to note that the interface specification is located in the client class namespace.

SVI Child : Note that the Interface (SVI) has nothing to do with the pattern functionality. An identical functionality exists in the C++ SPD pattern unit without the SVI specification. This shows that the effects of Simple Virtual Inheritance (SVI) can be factored out in any functional partitioning issues (via inheritance) within the pattern unit. Only GVI, because of its parent use context (of the virtual code elements), can effect pattern functionality via inheritance (as is shown in the C# SPD example above).

Execution Point Contract : Note that the contract for the surface API of the SPD pattern unit is NOT the same as a contract for the target functionality (within the pattern unit). Interfaces, a form of virtual inheritance (SVI virtual code elements), only provide an 'interface specification'. No specification of the actual functionality (provided by the interface) of the pattern is provided.

Object Aggregation : Since C# does not have Multiple Implementation Inheritance the example must contain, create and 'surface replicate' functional support members (such as methods that exist at the pattern surface API).

Aggregate Construction : Unlike MII in C++ the Internet_child and Database_child require construction code at the execution point (Construction burden of aggregates).

Surface API Replication : Unlike MII in C++ the Get_local_highest_state() and Get_global_highest_state() support methods must be replicated at the execution point (surface burden of aggregates).

The code features of the C# SPD implementation above combine to form a single functional unit abstracted at the execution point surface. The functional system, formed by the pattern participants, can be seen as a 'single balanced unit of functionality' which is the pattern implementation (pattern unit). Balance is achieved via Functional Normalization among the participants.

The example above shows a common use of Virtual Inheritance (VI - code element specification via inheritance) in the form of GVI (parent use context) and SVI (client use context). The most important aspect presented in the example is that SVI is external to the pattern (external contract) while GVI is internal to the pattern (internal plumbing).

Summary of Virtual and Interface inheritance in Object Oriented Languages

Virtual Inheritance (VI) is the specification of code elements via inheritance. The virtual code elements produced by the specification have either a parent use context (GVI) or a client use context (SVI). The use of SVI and GVI is presented in the context of Class based functional units. In this case (class based design) the following hold true.

GVI is an intra-pattern mechanism : It provides parental control of virtual code elements (parental use context). GVI can leverage the features of MII more than it can SII. This is because SII based designs use object aggregation/composition which lacks the lines of inheritance needed for GVI functionality.

SVI is an inter-pattern mechanism : It provides client control of virtual code elements (client use context). SVI has no effects via inheritance other than the forced implementation of the specification. As such it can not be used within the pattern unit for parental control (no parent use context).

The internal/external comparison of GVI/SVI in pattern unit design is valid for class based functional units like High State Tracker. System level component design patterns, on the other hand, use component based participants to form functional pattern units.

Component level patterns, which bind together complex pattern participants, may use SVI internally as contracts between participants. These types of systems are generally loosely coupled and non-performant in comparison with tightly coupled high performance pattern units like High State Tracker.

Use context, lines of inheritance and participant bindings (class/component) are important foundation concepts in understanding the role Virtual Inheritance (VI) takes in the object oriented design process. The coexistence of GVI as internal plumbing compliments SVI as external contract.

It is clear from the example that virtual code element design (the specification process) starts with WHO will be using the elements. Internal parents, external clients and participant binding are the three perspectives to keep in mind to distinguish the architectural benefits of GVI and SVI.

Java

public class Human
}


public class Mutant extends Human 
}


public class Program 
}

Semantics

It is necessary for the terminology of object-oriented (OO) computing to articulate the phenomena of Virtual Inheritance precisely. The terminology should reflect the conceptual semantics of the core computing phenomena rather than the syntactic mechanisms of any one object-oriented language.

Ideally the conceptual semantics and syntax mechanisms of OO code elements are identical but this is not always the case. The rapid evolution of computer science has accelerated the semantic evolution of its core terminology.

It has become a common industry practice, therefore, to provide qualifiers and acronyms (if needed) for terms that vary in their conceptual meaning due to use in a specific context (generally a particular computer language syntax).

In Implementation inheritance (II), for example, there is

• MII
• SII
• MI - SII plus Interfaces

A case in point, Virtual Inheritance (VI) as distinguished from Resolution Inheritance (RI) within this WikiPedia article (see C++ Resolution Mechanism). In order to better articulate this difference the conceptual semantic scope and history of object-oriented language syntactic mechanisms is briefly addressed.

The semantic scope and history of Virtual Inheritance is articulated in the sections below. This articulation helps to clarify the 'General' aspect (GVI) of 'Virtual Inheritance' from subjugated concepts such as Virtual Functions (as subset of GVI) and language specific meanings (i.e. C++ RI, etc)

See also

This 'See Also' topic map provides links to articles related to Virtual Inheritance (VI).

Virtual Inheritance is best understood within the context of class inheritance (all forms of inheritance). In the same way, Class Inheritance (CI) is best understood in the context of relevant design approaches (for combining computing functionality), issues and problems in software architecture.

The sections listed below help to distinguish the concepts of 'functional dispersion/aggregation along lines of inheritance' (as in Virtual/Implementation Inheritance) from 'object aggregation/composition' as embedded/referential members in a class (embedded/referential containment).

Note the interesting semantic distinction between the AGGREGATION of 'self reliant' objects from the COMPOSITION of 'object parts' (from the English language - 'composition' semantics infers 'composed of parts').

Similar subtle but important distinctions (semantic aspects) exist between virtual, implementation, multiple (MII) and interface inheritance.

Fundamental Inheritance Concepts

This section contains links to articles relevant to the general concept of inheritance.

• Class (object-oriented programming)
• Hierarchy (object-oriented programming)
• Inheritance (object-oriented programming)
• Type Polymorphism (computer science)
• Subclass (computer science)
• Superclass (computer science)

Detailed Inheritance Concepts

This section contains links to articles explaining the conceptual details of inheritance.

• Functional normalization (object-oriented programming)
• Implementaiton inheritance (object-oriented programming)
• Interface (computer science)
• Method (programming)
• method overriding (programming)
• Multiple inheritance
• Virtual function
• Virtual method table

Other Design Approaches

This section contains links to other ways of combining computing functionality (object aggregation/composition). Links to these concepts are listed to contrast inheritance from other approaches to functional design in object-oriented languages.

• Object Aggregation (via referential containment)
• Aspect-Oriented Programming (quantification/join mechanism for separation of code)
• Object Composition(via embedded containment)
• Function Composition (via sequential effects)
• Composition (disambiguation page)
• Object Association (aggregation Vs. composition semantics page)

Inheritance Issues and Problems

Many design problems in inheritance occur not because a mechanism (VI, II, MI, Interface) is 'bad' but because the right tool (mechanism) wasn't used for the right job (like using a hammer for a screwdriver). The problems below are not inherent to semantic mechanisms (which define the MEANING of a lanuage specification). These problems ARE, however, inherent to poor software design (actual language mechanism misuse in jave, C#, C++ etc.) or poor language implementations (bad compiler architecture/language specification/language design).

• Diamond Problem (state space collision)
• Fragile Base Class Problem (unintended child side effects when changing base class)
• Yo-yo Problem (complex inheritance structure)

Note also that syntax mechanisms should not be confused with conceptual semantics. You can not take a specific language specficiation and reverse engineer its syntactic mechanisms (what the compiler SHOULD generate) into the conceptual semantics expressed in the English (Human) lanaguage.

The supposion that inherently difficult and complex processing should suddenly become simple and trivial is also incorrect (i.e. an automobile is NOT as complex as a nut and bolt).

In the same way, each inheritance mechanism (VI, II, MII, etc) has logical semantic aspects that pre-exist ANY particular language implementation generated by a compiler (cause/semantics precedes effect/implementation). This perspective is important in distinguishing a poor software design (expression mechanism misuse) from a poor mechansim specification/implementation (language specification problem, compiler design problem).

Design Intentions in Inheritance

Virtual Inheritance (VI) is one of many object-oriented mechanisms used to achieve a design intention. Object-oriented software design intentions are generally guided by the principles listed below.

• Abstraction (Overview of conceptual partitioning mechanisms - class, module, etc.)
• Code Reuse (functional migration of replicated child code to parent class)
• Delegation (historical semantic issues)
• Encapsulation (disambiguation page)
• Information Hiding (principal underlying encapsulation technique in object-oriented programming)
• Separation of Concerns (no functional overlap)

Functional Normalization

Functional normalization is the removal of needlessly replicated code. This section contains links to articles related to concepts relevant to this process.

• Functional normalization (object-oriented programming)
• Orthogonalization (mathematical normalization)
• Aspect (functional perspectives orthogonal to core concern)
• Core Concern (the intrinsic and inherent core functionality of a class)
• Cross-cutting Concern (common functionality orthogonal to core concern)
• Refactoring (restructuring software)
• Database Normalization (minimize needlessly replicated data)

Logical Context of Virtual Inheritance

Virtual Inheritance may be categorized and classified under the following headings.

• Inheritance
• Object-oriented Programming
• Computer Science

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.