>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.
>
>You could do it that way. But what happens when another attribute comes along- e.g. pension plan, initially offered to FloorCleaners and managers but not salespeople? Where will you insert your new class this time?
>
>Seems to me that complexity grows exponentially if you persist more than a few levels with this route. You'll also create duplicate functionality that can no longer be changed in only one place.
>
>Now add in multiple customers with different bonus structures, dental plans, company cars, expense accounts, whatever. Will you maintain a separate source code version with a different class hierarchy for each customer?
>
>Perhaps "bonus earner" should be an attribute of all employees. Then the attribute can be switched on/off or overridden at a given level. Then you could give customers control over bonuses/pensions/health plans/dental/whatever without requiring programmatic parentclass changes every time.
>
>I know it's just an example, but sometimes the easy road leads you straight into the bog. ;-) I'm just trying to understand why easier parentclass definition changes is something I might plan to make routine use of in NET. It's not a major, I've just seen some very smart people focusing on it and I don't want to miss something useful.

Hi TJohn (and Tracy)

I refer to my original quiestion: "if you have the ability to easily insert classes into an existing hierarchy...." - note the 'easily'. Of course as a class hierarchy becomes more difuse then it will often be more difficult, or even impossible, to identify a point where inserting a class would work and then obviously Interfaces are (pretty much) the only option.

I'm also not suggesting, as maybe you feel, that the ability to quickly change an existing class hierarchy should be used as an excuse for sloppy design in the first place - but I admit to regularly making such changes as a project progresses. When I came to a situation like that in VFP I'd try to avoid changing the inheritance and use a work around. In .NET I just do it.

Best,
Viv