>>I'd turn that around. If using class inheritance is an option why would you opt for an interface?
>>
>>It would depend on your reasons for wanting to change a parent class, which is why I asked for examples. So far the examples relate to exceptions in VFP rather than a planned process that benefits from the comparative ease in NET. Excuse the naff metaphor(!) but while it may be easier to find a coconut in Rarotonga than it is in Wales, that only matters if you need a coconut. ;-)
>>
>>if you have the ability to easily insert classes into an existing hierarchy where that is the best solution why would it not be best practice to do so......
>>
>>You'd need to start by explaining why it is the best solution ;-)
>
>OK. One of the usual standard hierarchy examples:
>Class: Employee
>Derived classes: Manager, Salesman, LineWorker, FloorCleaner
>
>Now a requirement comes along to give bonuses to FloorCleaners and Salesman. Since they both derive from Employee then it makes more sense to insert a BonusEarner class under Employee and derive FloorCleaner and SalesMan from that.
>If you go the Interface route you have to implement the BonusEarner related methods and properties in two places (and this is a simple example - you might have to do it in a lot more places than that) plus if the interface needs to change you have to repeat the process. And if managers ever need to get a bonus you have to repeat the process again.
>Makes no sense to me to do that when reassigning the inheritance in .NET is a simple change.....
>
>Maybe I'm missing something - can you give an example where using an Interface *would* be preferable?
>Best,
>Viv

Sure, if you had contractors and interns as well. They could all implement pay, bonuses, training, insurance, or not. Some may be allowed visitors, others not. You could implement some, all, or none of the interfaces. I would use class inheritence and abstract classes where the definite 'is-a' relationship occurs only. I would probably have a combination of abstract classes and interfaces.