.NET and Multiple Inheritance

Thanks to LinkedIn, I hooked up with an old colleague from SR Telecom last week. We had only worked together for a few months, so I asked him if he still remembered me. He replied with the affirmative and asked me if I still hated multiple inheritance.

"Of course I do and thankfully I'm working in VC#.NET which has interfaces that you can use in addition to abstract or base classes!" . My friend replied that he is still using (abusing!) multiple inheritance and C++ at his new job. I got the impression that he still likes it, in spite of his many years of work experience. That begs the question : has he ever had to maintain any of his code ?

Luckily, I got my first taste of multiple inheritance early in my career when I inherited someone else's code. At first, I was impressed with the complex structure. I felt that my predecessor had left me a clever puzzle to decode! Tracking down the final implementation of virtual classes that had been specialized in a child class of two incestually related parents was a good challenge for a junior programmer. However, I quickly tired of this task and joined the growing ranks of weary developers who wanted better rules so that they could get on with building features instead of tracking down bugs.

Since then, I have not been called in to clean up any other multiple inheritance code. Now, that I've been doing VC#.NET for a year, I am hoping that I won't ever have to go back to it again.

Interfaces are a clean solution for allowing designers to present a "tailored" view of their objects for various clients while still allowing for sharing of common code through specialization.

I'm still using .NET 2.0 so I'm looking forward to using mixins on 3.0. That reminds me, I better get searching for a free trial version of it to play with.