I found the content of articles from Tracy's links quite confusing.

The first is one starts with "From a design perspective you must ask yourself, Will a Class fully represent an object?" - apart from the total nonsense of the question, since when classes "represent" objects? Then it pretends to clarify with "Meaning that, if we have a base class with abstract methods designed for a particular application and we know that the inheriting object will only need the methods defined in that class." The little English I knew must have deserted me, this sentence looks like a head without a body. The "Automobile" class comes out of nowhere, and so on... Very difficult to stay focused on such reading.

The 2nd and 3rd (3rd also difficult to read) state that multiple interface inheritance does not have the problems of multiple class inheritance, but, to be honest, I don't see much difference. An interface can inherit from multiple interfaces, so you could evolve a spaghetti like interfaces hierarchy. Then, don't you still have diamond-like problem, when a class inherits from multiple interfaces that contain members having the same signature. You solve the problem by explicit implementation, which is similar with what you do to solve the diamond problem in multiple class inheritance. I interpreted what Anders said as it was easier to do the MI with interfaces in the compiler, not that it eliminates the MI problems for the developers.

In any case, my point was only that there is a debate about multiple inheritance (classes or interfaces, simulated or true), and my perception is that there is a general consensus that MI is bad practice. I doubt I can add anything original to the debate, except for, maybe, some inaccuracies ;)

>Doru,
>
>Ah, but what I'm talking about isn't true multiple inheritance. I agree that that can get very messy. But having classes that implement multiple interfaces solves this problem nicely.
>
>Here's an apropos quote from one of the links that Tracy posted:
>
>Multiple interface implementation is a compromise. It enables you to have multiple interface inheritance, without all of the problems associated with multiple implementation inheritance
>
>And, in the link from Tracy that was a Q&A with Anders, he says:
>
>I think also when you analyze what is it that people want to do with multiple inheritance, in the vast majority of cases I think there are simpler answers than the full multiple inheritance enchilada with virtual base classes and the diamond problem and all of that stuff.
>
>And lastly, Perry's reply to you was spot-on! He said it much better than I have been trying to say. Thanks Perry! =0)
>
>~~Bonnie
>
>
>
>
>>>>>... Interfaces can be used to simulate multiple-inheritance. And there's nothing wrong with using them this way.
>>>>
>>>>Nothing wrong? I believe that this is, at least, debatable.
>>>
>>>OK, I'm always up for a good debate ... what are your objections?
>>>
>>>~~Bonnie
>>
>>I believe that multiple inheritance (MI):
>>- in most cases, shows a flaw in design.
>>- and almost always generates maintenance problems.
>>I put MI in the same category with things like the Scope Resolution Operator, or event binding. We all hated spaghetti code (sometimes, even if it was our code) for the mess it created, but we were all so happy to get the :: and event binding.
>>A complex class hierarchy that uses single inheritance could be challenging, but with MI you can really make it like spaghetti.
>>
>>I know that in real life we have to compromise, sometimes, and for valid reasons, use interfaces to simulate MI. Some say MI is good, and some say MI is bad - I don't know if there is a clear winner, but I am on the side that believe there is enough wrong with MI. Maybe you meant there is nothing wrong technically, i.e. you can do it, which is true.
>>
>>I wasn't actually looking for having the debate here, there are people way better than me to do it. I just felt "nothing wrong" was too strong.