One of the first examples of OOP I encountered was the old 'shape' hierarchy demonstration:
'shape' is a base class.
'rectangle' is a new class that inherits from shape.
'square' inherits from 'rectangle', etc.
It demonstrates the ".. is a .." relationship that inheritance describes perfectly.
This is a pretty common way to introduce OOP as it draws on stuff we all know intuitively. The example proposed with a bunch of drum machines concepts, trash, timers & stripes or whatever is so mind bogglingly obscure for most people that I'm sure they would have checked out long before the actual OOP lesson begins.
Not sure what the point is.
Oh, and btw, just because you might not ever need to represent a 'duck' object, doesn't mean that it is a stupid example. Say I write a game with a bunch of actors, I might have a base actor class, a bird class that extends that, and a duck class that extends that. Bam, legitimate use for a 'duck' object. There's probably a lot more people wanting to write "a clone of the sims" than "an intractably obscure drum-machine".
> 'square' inherits from 'rectangle', etc. ... It demonstrates the ".. is a .." relationship that inheritance describes perfectly.
Your comment is a perfect example of why this is a terrible way to teach object-oriented design: if your squares and rectangles are mutable, as they usually are in the old shape-hierarchy demonstration, you've just violated the LSP and introduced a subtle bug into your program, in the very first line of your comment. If you understood object-oriented design, you wouldn't do that. You've been tricked into thinking you know how to do object-oriented design, but your sense of competence is an illusion.
For what it's worth, although I don't have any real experience teaching other people to program, I've found that animated graphics that make sounds hold the attention of nontechnical people a lot better than abstract hierarchies of Platonic geometric shapes. I haven't compared them with bird-flocking simulations.
It demonstrates the ".. is a .." relationship that inheritance describes perfectly.
This is a pretty common way to introduce OOP as it draws on stuff we all know intuitively. The example proposed with a bunch of drum machines concepts, trash, timers & stripes or whatever is so mind bogglingly obscure for most people that I'm sure they would have checked out long before the actual OOP lesson begins.
Not sure what the point is.
Oh, and btw, just because you might not ever need to represent a 'duck' object, doesn't mean that it is a stupid example. Say I write a game with a bunch of actors, I might have a base actor class, a bird class that extends that, and a duck class that extends that. Bam, legitimate use for a 'duck' object. There's probably a lot more people wanting to write "a clone of the sims" than "an intractably obscure drum-machine".