>PMJI, this interests me because it is confusing. I agree with the problems and not long ago I read about the diamond problem encountered in multiple inheritance. I think it still holds true. For example, if class D inherits from both class B and class C, and both B and C inherit from A like below:
>
>

>  A
> / \
>B   C
> \ /
>  D
>

>
>Which copy of A should D get? Should it get the one from B or the one from C? Or should it get both?
>

The diamond problem has solutions, but to me the problem is more in the spaghetti structures that MI allows.

>However, I saw a very good and very basic example of simulating multiple inheritance (when it makes sense) using a class implementing more than one interface here:
>
>http://www.c-sharpcorner.com/UploadFile/cbreakspear/MultipleInheritance11082005004843AM/MultipleInheritance.aspx
>
>and here:
>
>http://en.csharp-online.net/Common_Type_System%E2%80%94Multiple_Inheritance
>
>I like Anders comments on it here:
>
>http://msdn.microsoft.com/msdntv/transcripts/20040624csharpahTranscript.aspx
>
>Frankly, I've read a few articles on it and I'm left feeling baffled more than anything else. I think I will avoid it whenever possible and if absolutely necessary, use it sparingly. I wrote that knowing full well that anytime in the past I declared 'I will never,' I typically ended up at least once having to do exactly what I swore not to :o)
>

Reading the articles in you links confused me too (see my answer to Bonnie). As to using MI (or similar, in my view, features, like bindevents, scope resolution operator, etc.), as you say, it's almost impossible not to use them as long as they are available. It is like never going over the posted speed limit.

>
>
>>>>>... 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.