I wrote inline comments.

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

Why would you use an interface for this? For functionality that every class might have, isn't a base class better?

Let's say you have 20 classes derived from classA, and you discover you need a new function FNew1() for all 20 classes.

If you have a base class, all you need is to add the FNew1() to classA, and rebuild you projects.

If you define a new interface INew1, you need to change all 20 classes to implement INew1, and also write implementation code in each of the 20 classes, even if the code is exactly the same. It already looks more complicated than the base class solution.

Now, if you don't have a base class for the 20 classes, or if you can't change the base class, then I guess interfaces could save you. The next time you need new functionality, maybe for only 10 of the 20 classes, you again define INew2, and change the definition of 10 classes, and write code in 10 places. Now you have 10 classes implementing multiple interfaces, and depending on how many things are added, it could became complex even without any spaghetti in the interfaces hierarchy. Interfaces and multiple inheritance from interfaces do solve the problems, but if I had a choice I'd do the original design so that it avoids MI.

>
>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 I said before, I believe avoiding MI is part of good class/interface design. It was a comment to Bonnie's assertion that there is nothing wrong in using interfaces to simulate MI - again from a design POV.

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