Firstly - Excellent Post Geo!!!

In an instance like the above, what's really needed is to re-use those objects that apply, and develop new ones for those that don't after a thorough analysis of the problem.

Boy I've personally learned that the hard way. But I think maybe I look at handling this sort of situation a little differently than you perhaps. In an effort to learn from past mistakes, whenever I encounter a need for partial reuse of a class I usually see 3 options:

A) Do you like your example and subclass what I already have and use some stuff/overwrite other stuff.
B) Create a new object and repeat the stuff I want to reuse.
C) Build a new abstract superclass with the stuff I want to reuse, re-create my original (partially useful) class as a subclass of new abstract parent, and create the new class I needed in first place.

For me, time has proven C) is usually the best choice solution becuase when the same scenario presents itself again - I already have my superclass! Also, another thing that commonly happens when I'm pursuing C) is that I discover the reason I didn't create the abstract parent class in the first place is that the situation did not seem very cut-and-dry the first time around, so therefore I didn't see alot of room for reuse initially. At this point another learn-from-past-mistakes light goes off (where I rewrote the abstract parent class 3 times until I got it right for all new/unexpected needs). I now automatically figure that if I didnt see the possible reuse the first time around, then I tried to put too much into 1 object. So I like to fall back on one of the GOF OO principles of "Favor object composition over class inheritance".

Following this principle, now when I go to create my abstract parent I try to setup it so that the the intended subclass functionality gets rolled into an aggregate object. And I'm sure you know where I'm going here - what I initially thought of as a generic superclass ends up not being so abstract after all and I'm left with nice simple generic ( and often concrete) class with a plug-in aggregate to fit my specific need at runtime flexibility. Nice pot-of-gold and the end of the rainbow IMHO because I just eliminated any complicated inheritance hassles, prepared myself to handle anything similar that might pop up in future, and my class heirarchy stays neat & clean. I've been taking this approach right from the start for a few months now and have yet encountered the all to familiar "go back and rewrite again a month later" hassle like I did with learning this through my above A), B), C) trial & errors.

So I'm curious as to your (or anybody elses) opinion on this approach? I sometimes wonder if automatically reaching for the aggregate object for specific functionality is overcomplicating things, especially if something "new" in regards to partial reuse never pops up.