On the one hand, using examples which do nothing more than print "quack" is a bit of failure of imagination on the teacher's part. But then, _needing_ an example to do something other than print "quack" is a failure of imagination on the student's part.
You had, I assume, seen functions before.
If I were teaching such material I would keep the content of the functions themselves as simple as possible to allow the student to concentrate on the novel material. Once I had established that the student understood the principle we could then examine or at least discuss more "real world" cases.
If we go back to the original article for a moment, I can far more easily see an immediately accessible problem-set emerging from bird / duck / penguin (e.g. programming the behavior of animals in a virtual world) than a particular drum machine whose operation might make no sense to many people. Are ducks a "subclass" of bird? How do we handle the face that penguins and ducks can swim and penguins can't fly? Is it useful to consider be the penguin as a "bird" at all. Perhaps we shouldn't have a "bird" class but an "animal" class. Should we do multiple inheritance? Mixins? Templates? Perhaps we'd be better with an "animal" class and allow some animals to fly and some to swim? Are complex classes like this bad? How could all these different approaches to OO design be applied?
Now explain to me how a drum machine illustrates these problems in a way everyone can immediately appreciate.
>> Now explain to me how a drum machine illustrates these problems in a way everyone can immediately appreciate.
A drum machine may not be the best example (as the author mentioned) but it is a concrete example. You argue that an animal based example illustrates all these different possibilities in an object oriented approach.
>> Are ducks a "subclass" of bird? How do we handle the face that penguins and ducks can swim and penguins can't fly? Is it useful to consider be the penguin as a "bird" at all. Perhaps we shouldn't have a "bird" class but an "animal" class. Should we do multiple inheritance? Mixins? Templates? Perhaps we'd be better with an "animal" class and allow some animals to fly and some to swim? Are complex classes like this bad? How could all these different approaches to OO design be applied?
The problem is that this is completely divorced from anything that any sane person learning programming would want to do.
Sure, printing "quack" is interesting for the first page of a tutorial, but I would expect that the usefulness of the examples in a tutorial would scale with their difficulty. If you're using multiple inheritance, mixins, and templates, you should be using code that either requires these techniques or benefits from them.
Imagine you're a novice programmer. You've used a computer your whole life, and do awesome things with it every day. You want to learn how to make it do cool things. In and of themselves templates, mixins, and inheritance are not cool things. They are only cool if you know what they can help you do. A novice programmer will have no idea what they can help him do.
So, for a tutorial aimed at teaching someone their 12th programming language, use birds/ducks. But if you're aiming at teaching a novice, and you use a birds/ducks example you have almost certainly failed to keep your student engaged. Instead, go with something that doesn't cover all the bases, but starts to show how much work can be accomplished with some simple OO structures.
> The problem is that this is completely divorced from anything that any sane person learning programming would want to do.
It sounds to me a lot like a typical game-programming kind of design question. Games are pretty popular. Can you think of a more generally popular problem domain?
Certainly, one can imagine very similar examples (car / vehicle / truck etc.) which would bear directly on very popular game analogies.
> So, for a tutorial aimed at teaching someone their 12th programming language, use birds/ducks.
I think your point here is well-taken. If the student knows about conventional programming, introducing OO coding is a different task than otherwise. But the whole 'print "quack"' point is pretty silly -- of course you'll initially teach about inheritance using trivial functionality that doesn't distract from the teaching point. I've seen OO tutorials that talk about point, square, and circle classes that never actually draw a point, square, or circle. Is printing "width = 100" more profound than "quack"?
In the end, you teach a topic by focusing on that topic, not adding a bunch of distracting detail. The distracting detail may be useful for motivation, but you need to get it out of the way to actually explain the point.
I might finally add that teaching a specific person you're talking to is a different task than writing a book. When you're teaching a specific person you can find out what they're interested in and use that as both motivation and example. But, if you're writing a book you want to find analogies that are are universally accessible and appealing as possible.
You had, I assume, seen functions before.
If I were teaching such material I would keep the content of the functions themselves as simple as possible to allow the student to concentrate on the novel material. Once I had established that the student understood the principle we could then examine or at least discuss more "real world" cases.
If we go back to the original article for a moment, I can far more easily see an immediately accessible problem-set emerging from bird / duck / penguin (e.g. programming the behavior of animals in a virtual world) than a particular drum machine whose operation might make no sense to many people. Are ducks a "subclass" of bird? How do we handle the face that penguins and ducks can swim and penguins can't fly? Is it useful to consider be the penguin as a "bird" at all. Perhaps we shouldn't have a "bird" class but an "animal" class. Should we do multiple inheritance? Mixins? Templates? Perhaps we'd be better with an "animal" class and allow some animals to fly and some to swim? Are complex classes like this bad? How could all these different approaches to OO design be applied?
Now explain to me how a drum machine illustrates these problems in a way everyone can immediately appreciate.