Software design pattern for achieving clean multiple inheritance in Object Oriented Programming

A method for achieving clean multiple inheritance in object oriented programming, wherein the programmers can specify on an individual bases whether each of the inherited data fields should be joined or separated in the sub-classes, when applied to the OOP languages that support native multiple inheritance (such as C++, Python, Ocaml, Lisp, and Eiffel, etc.), the method compromising the following implementation steps:

• a. for each class the programmers want to model, split into two classes, the first is its data interface class and the second is its data implementation class, and:
• i. the data interface class only defines the abstract virtual accessor/property methods for each of the class' fields but does not define the raw data fields themselves, and defines other concrete regular methods using these abstract virtual property methods;
• and
• ii. the data implementation class inherits the data interface class, defines the actual data fields, and overrides or implements the concrete virtual property methods using these actual fields, or using computation instead of raw data fields;
• and
• iii. define one or more factory methods, which create an object of the type of the data implementation class and return it as the type of the data interface class;
• the said factory methods can be defined as global free functions, or as the data interface class' static member functions;
• and
• b. for each sub-class:
• i. its data interface class inherits from its (multiple) super-classes' data interface classes, and can optionally choose to overrides any of the inherited virtual properties depending on the computer program's application semantics;
• and
• ii. implement the sub-class's data implementation class independently from its super-classes' data implementation classes, wherein it can still optionally inherit from one of more its super-classes' data implementation classes, but it is not mandated to do so;
• and
• c. for each field that is semantically branched [0018 Definition 2]:
• i. in each data interface class of the sub-class that is immediately below the semantic branching site [0018 Definition 2], introduce a new abstract semantic assigning property, which use a different name from its original field name;
• and
• ii. each regular method in the sub-class' data interface class can optionally choose to use the said new semantic assigning property introduced in the previous step (1.c.i) depending on the computer program's application semantics.