Hmmm. I have to say that sounds like a great over simplification.

Surely there are a lot of cases where enforcing a base class behaviour (constructors,etc) is essential.
And Interface inheritance can get messy. Try, for example, changing the base interface definition late in the day and then tracking down all the types that implement derived interfaces that will now be invalid....
Plus methods implementing an interface must be public so it is not possible to limit their scope....

>Interface inheritance good. In general, implementation inheritance bad.
>
>>In the early days of .NET (1.0 and 1.1), there were some WinForm controls that didn't work quite right and sub-classing them was the only way to get around their quirkiness (ComboBoxes come to mind, I think ... it was a long time ago <g>). Plus, it seemed at the time, that I was always needing to add some functionality to a control (TextBox or whatever), that was needed throughout my application. So, we sub-classed everything. Now, granted, I had just jumped from VFP to .NET, so perhaps it was out of habit. But, at the time, it seemed the only way to solve the issues we were having.
>>
>>Not sure what point you're trying to make about interfaces ...
>>
>>~~Bonnie