A decision has to be made in this case.

And the usual decision is to have a base class that has the method code to be shared across multiple specific subclasses of a base class. So you have a getname method in the person baseclass that shared among employees, contractors, outsidesalesrep, etc. classes.

Then have interfaces define the methods a class must have to implement functionality that a class might have regardless of it's type (person, transactiontype, jobtype, etc.)

In my example, I only list one interface, but there could be several. As I said before, implement an Interface to serialize a class, to save a class, to sort a class, etc.

So I don't think it gets as complicated as you are thinking it might. In good class design you avoid the situation you are describing.

As a matter of fact, it doesn't appear your example would ever happen. Say you have an interface that defines the class contract for sending something. You define what's necessary to email information, ftp it, etc. Then one day you get a new requirement to add SFTP sending, but only in some cases. So you would define an Interface that inherits from the sending Interface you've already defined, and adds its own methods for SFTP.

In the classes that need to implement SFTP processing, you just change the Interface that it implements from the first interface to the one that inherits from the first interface, as well as adds the SFTP methods.

So if the base interface is IA and you create IB which inherits from IA and adds SFTP methods, your class would only have to implement IB.

Reading this kind of stuff without seeing examples can make your head spin. But it's really not too difficult.

If used properly, this functionality does aid in creating bug-free and robus code. You could never use an interface if you don't want to. But it enforces common code across your app. Get's back to the phrase Bonnie used, "Code to the Interface, not the implementation".

The point being that in my example, you don't care, and don't need to know what class wants to send. Every class that wants to send SFTP will have the SendSFTP method you defined in your interface. There might be some differences in the particular code in the method in the class that actually defines the method. But you don't care.

So in this example, you might have another class that actually implements the sending of SFTP files. It only knows it needs to call the SendSFTP method of the class that instantiated this sending class. When you create a new type of business class, say you're having to add a new kind of person, a professor for a college system, bugs encountered during the upgrade should be contained to the professor class because the class that implements the sending doesn't need to be touched.

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