>Vlad Thank You!!! I understand now, this is by far the best example of MI I've ever seen.

Here's another example from a real application I developed in the past year. The app was developed in Java, so, no multiple inheritance. But MI could be very useful and it could make the code simpler and smaller.

I have a hierarchy of entities:

Company
  +-- Customer
        +-- Network
              +-- Subnetwork
                    +-- Node
                    +-- Link
  +-- Sales department
        +-- User

We used a treeview control to display this hierarchy to the user. The tree structure is also very useful in our generic mechanism that manages the displayed data (any entity, at any level, can "walk" up the tree and determine all the relations to uniquely identify it).

So, we want each entity to be a tree node. We also want to define some standard behavior for the base entity. We used a third-party treeview control, so, we cannot modify the base treenode class. Since the Explorer kind of user interface becomes more and more popular, the same design problems appear in any app that deals with this type of UI.

So, there are several solutions:
1. Each entity is a tree node. That means the BaseEntity class must be derived from TreeNode. So, all the basic behavior will be defined in this class.
2. BaseEntity is a separate class. It will have a link to a TreeNode object.
3. BaseEntity is a separate class. We derive a new BaseTreeNode class that has a link to a BaseEntity object.
4. BaseEntity is a separate class. All specialized entities are derived from TreeNode and BaseEntity. That means multiple inheritance... and it is not available. :(

Obviously, in 1, 2 or 3, all specialized entities are derived from BaseEntity.

Solution 1 is not very good because it does not clearly separate the TreeNode behavior from the BaseEntity behavior. People have problems separating them in specialized entity classes, too.

Solution 2 and 3 are better but they are not perfect. Some people see the entites more like nodes in the hierarchy, so they want the BaseEntity class derived from TreeNode. It is also very difficult to predict which one will make the code simpler in the long run. Should a TreeNode own an Entity or an Entity should own a TreeNode. Is it possible to have TreeNodes without an Entity or/and Entities without a TreeNode? Of course, one could have links in both ways. This is much better for the readability of the code, but it also introduces the problem of circular ownership/references, so, when/where the double link should be broken.

Since in "real life" a specialized entity is a BaseEntity and it also is a TreeNode, then it should be derived from both classes. The MI comes as a natural solution here and it would make many design problems disappear.

Vlad