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.