>
See my reply to JVP. I'll agree that the interface is the key here. However, there are situations where it is very easy to say, "Well, I need the default behavior of this object, so all I have to do is issue a DoDefault, and all is well." Then, down the road, that underlying behavior has to be modified (for whatever reason), and, all of a sudden, that object no longer works correctly.
>

This is not polymorphism. This is a question of whether you override inheritance or not....

>
The real key, in my POV, is the definition. What is it supposed to do? Each time I find my self in a position where I have something that "sort of, kind of" does what I need, I re-examine not only the problem, but the solution as implemented as well. I'm a big (and I mean big) believer in the use of abstract classes that define not much more than the interface.
>

Behaviors can change based on a variety of circumstances. Once again, this is where inheritance is over-used. It is far better to rely on a pattern approach -Chain of Responsibility in this case, and make use of aggregation. Once again, looking at the VB world, which does not have inhertiance, they do this stuff all of the time. This is why many VB'ers look at you funny when you tell them about how great inheritance is. They often say "so what" They use patterns all of the time, they just don't use the jargon that much.

I think your use of polymorphism is a mixing up of metaphors...