Your example has class inheritance plus one interface inheritance, so it can be called multiple inheritance, but it is, as you say, different.
What I had in mind was an interfaces structure that uses multiple inheritance, and then using interfaces to simulate multiple inheritance for classes. Something like interfaces IB and IC inherit from IA, then ID inherits from IB and IC, and IE inherits from ID and IA... Then you have a class that implements IB,IC and IE.

In your example, is it better to use an interface as opposed to, let's say, a BusinessData class, having the basic save methods, as a base class for the Person and Job classes?
Using the interface you must write code in each class for the methods declared in the interface.
Using BusinessData base class, you could do the same. But you could also write generic code that applies to most or all classes, and you can always overwrite it, if it does not apply.

>I think it's different in this case. Have you ever seen a dotnet class that implements several interfaces? Or inherits from a class and implements an interface or 2?
>
>It has the possibility to make your app more robust and cleaner. For example you can define an interface that has some basic methods to deal with business classes. Just for grins it might have some basic save methods for backing up the data before your changes are made. Which can be used across multiple classes that have no real relationship. You will do the same algorithm for saving the data no matter what type of class it is.
>
>If you have an employee class, this can inherit from your base person class, and implement your interface with the basic save, etc., methods. You might have a job class, that inherits from another base class, but also implements the same interface.
>
>Because both classes implement the same interface, you are assured that no matter what the class is, you call the same methods to save.
>
>That's why you see interfaces such as ISerializable, ICloneable, etc. Use Interfaces for functions that will operate across disaparate classes.
>
>Use base classes to implement class functionality particular to that class, but interfaces to help define basic class functionality. Makes for a much more readable program.
>
>
>
>>>>>... 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.