It also helps to put the classes higher in the source file than the uses of them (which matches how classes get used when in separate files). The good practices that you described are also ways to overcome not using this "natural order" but it can still be a good idea to stick to the usual order.

I'll also note that the original code smells like a typical design made after reading a typical introduction to OO programming. Jumping to using inheritance is probably the most common mistake made by OO programmers who haven't yet become old and tired. Old, tired OO programmers have learned that an "is a" relationship is very tight and quite inflexible and so should be reserved for rather rare cases and only used for a very fundamental connection (and that fundamental connections can still usually be better implemented without inheritance).

It is funny that most OO books bang on about inheritance so much when the guy who invented the term OO thinks that OO is:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." -- Alan Kay

___________________
Jeremy
Bots of the disorder.

I think this is such a common pitfall, at least in part, because a person writing a tutorial about OO needs to mention and explain inheritance and so also feels compelled to explain the "power" and "benefits" of inheritance. The pitfall is going on and on about the benefits, rarely even mentioning the pitfalls, and using really sucky examples to explain all of the things that can be done with inheritance.

Though I'm often quite disappointed that tutorials on OO nearly fail to mention data organization, data hiding, and associating the code with the data it works on. Those are the big wins of OO for me.

- tye