How many people still try to fit their software design into the class hierarchy model? I've been on the composition-not-inheritance side for so long I can't do "traditional OO" justice, but I'd love to hear the counter-arguments in case I'm wrong.
How many people still try to fit their software design into the class hierarchy model? I've been on the composition-not-inheritance side for so long I can't do "traditional OO" justice, but I'd love to hear the counter-arguments in case I'm wrong.
The distinguishing feature of OO is modeling concepts by encapsulating state and behavior. For some reason, introductions tend to focus on complex inheritance structures instead. I think that's really unfortunate because it sends entirely the wrong message about OOP.
That said, I do occasionally use inheritance for polymorphism and limited code reuse (such as [1]), but I keep it limited in scope, and I don't think I've ever used a multi-level inheritance hierarchy.
[1] In my Let's Play TDD screencast series, I use inheritance when modeling a "Dollars" value object. There's a Dollars base class and then various specializations: ValidDollars, InvalidDollars, and UserEnteredDollars.
Source code: https://github.com/jamesshore/lets_play_tdd/tree/master/src/...
The screencast: http://www.jamesshore.com/Blog/Lets-Play/
Superclasses are just a special case of this.
In so far as I have never found a use case for a class hierarchy 5 deep I agree with him. On the other hand the argument that because you can do it wrong means you shouldn't do it all isn't compelling. I don't think there is a language or language feature that you can't use incorrectly.