6 ms·

Heh, I agree somewhat that the Duck>Animal is a bit annoying.. but this: Here’s an example that I think would be better to use instead: the `Visible` hiera

by d0m 15y ago

Heh, I agree somewhat that the Duck>Animal is a bit annoying.. but this: Here’s an example that I think would be better to use instead: the `Visible` hierarchy in [Pygmusic][], which is a kind of software drum machine. A `Timer` is a horizontal strip on the screen with a stripe racing across it. A `NumericHalo` is a spreading ripple on the screen that fades. A `Sound` is a thing on the screen that makes a sound when a `Timer`’s stripe hits it. A `Trash` is a thing that deletes `Sound`s when you drop them on it. They all inherit from `Visible`, which represents things that can be drawn on the screen and perhaps respond to mouse clicks or drop events, but they do different things in those three cases. In addition, the `Trash` and `Sound`s are subclasses of `ImageDisplay`, because the way they handle being drawn is simply to display a static image, so that code is factored into a superclass. Is by far worst.. The goal of the Person or Duck is to pick a trivial example to explain some concept. Of course you're not building Sim city and that it will be totally different in real apps. Also, it's true that inheritance is often the wrong solution and could arguably be said that it create more problems than it solves. However, before understanding all the pitfalls and the why/why not of inheritance, you first need to understand what inheritance is! So, instead of shooting someone who give an example with a Duck to explain OO, let just say that this tutor should say beforehand "Let's take a trivial example to understand the concepts of OO. Later on, we'll see why this is not always the preferred solution."

kragen 15y ago
Probably if you have a trivial piece of code, you don't need inheritance to help you structure it. But you're right that we need a smaller example than the entire class hierarchy of Pygmusic. What do you think would be the smallest sensible example? If your objective is only to explain what inheritance is rather than why someone would use it, you could probably write two classes and three methods: class A: def z(self): print "z " + self.y() def y(self): return "Ay" class B(A): def y(self): return "By" A().x() B().x() But I really think that most people will find a program easier to understand if it's not completely abstract like that — if it reflects some kind of intentional process where a programmer was trying to achieve something. But in order to explain inheritance in such a context, you need a program where inheritance makes things better instead of worse. What do you think is the simplest possible piece of code that would do that? I am thinking of a very-much-cut-down version of Pygmusic with only two drawable objects.
- spc476 15y ago
  Device drivers. You have a base class, device, which supports at the minimum, read() and write(). Then you subclass to block and character devices, and so from there. It's a real world example (Unix does it, although in C) and it's simple enough to explain the concepts.
  - jrockway 15y ago
    But delegation is a better solution than inheritance for this, i.e. the printer driver class takes a character device instance as a parameter. Delegate the character device's read and write methods to the printer driver's class, make the printer driver do the same interfaces, and done. Now you have something that composes better than inheritance and substitutes anywhere you needed a character device.
- riffraff 15y ago
  irc bots. Or chat bots in general since kids are not familiar with irc nowadays. It's an amazingly useful teaching tool, since it's real enough to understand it and fake enough that you don't care about taking the bits apart and replacing them. Also, it has a lot of points where you can go and improve the design (extract interfaces, get away with inheritance and use delegation, then get away with objects, then end up with a lisp interpreter etc etc).
podperson 15y ago
I agree that the proposed replacement is terrible. I'd suggest files are a great example for people who have a programming background because you can quickly show problems (e.g. streams considered as a subclass of files) that entail the kinds of tradeoffs and decisions the author rightly points out are shortcomings of the duck example (most of the shortcomings listed are in fact more a case of the author trying to show off and not problems with the example at all). But, you know what, duck, bird, and penguin are actually just fine. As the author himself (I assume it's a him) points out, penguins can't fly. And let's say that over hear we're doing vehicle, car, plane, and helicopter. How can we avoid implementing flying twice? And is it a good idea to treat flying like a plane, a helicopter, and a bird (but not a penguin) as the same thing. Oh, and the way penguins swim is amazingly analogous to flying, how can we leverage that? So, bye bye shitty drum machine example. I'm going back to duck and bird.
- Wilduck 15y ago
  As someone who is only a couple years past my first encounter with car/vehicle, duck/bird examples I can say that they did nothing useful for me. I think the reason they were so useless is not because they were trivially simple, but because they emphasize the wrong type of focus when dealing with inheritance. Presenting inheritance in terms of duck/bird emphasizes thinking in terms of similarities between nouns, which is misleading. I would have much rather seen some contrived example which does something other than print "quack". This, however, is a criticism with most tutorials that I've read. Most would benefit from having more substantive examples and letting the syntax and concepts fall out of them.
  - podperson 15y ago
    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.

by d0m 15y ago

kragen 15y ago

Probably if you have a trivial piece of code, you don't need inheritance to help you structure it. But you're right that we need a smaller example than the entire class hierarchy of Pygmusic. What do you think would be the smallest sensible example? If your objective is only to explain what inheritance is rather than why someone would use it, you could probably write two classes and three methods: class A: def z(self): print "z " + self.y() def y(self): return "Ay" class B(A): def y(self): return "By" A().x() B().x() But I really think that most people will find a program easier to understand if it's not completely abstract like that — if it reflects some kind of intentional process where a programmer was trying to achieve something. But in order to explain inheritance in such a context, you need a program where inheritance makes things better instead of worse. What do you think is the simplest possible piece of code that would do that? I am thinking of a very-much-cut-down version of Pygmusic with only two drawable objects.

spc476 15y ago
Device drivers. You have a base class, device, which supports at the minimum, read() and write(). Then you subclass to block and character devices, and so from there. It's a real world example (Unix does it, although in C) and it's simple enough to explain the concepts.
- jrockway 15y ago
  But delegation is a better solution than inheritance for this, i.e. the printer driver class takes a character device instance as a parameter. Delegate the character device's read and write methods to the printer driver's class, make the printer driver do the same interfaces, and done. Now you have something that composes better than inheritance and substitutes anywhere you needed a character device.
riffraff 15y ago
irc bots. Or chat bots in general since kids are not familiar with irc nowadays. It's an amazingly useful teaching tool, since it's real enough to understand it and fake enough that you don't care about taking the bits apart and replacing them. Also, it has a lot of points where you can go and improve the design (extract interfaces, get away with inheritance and use delegation, then get away with objects, then end up with a lisp interpreter etc etc).

podperson 15y ago

I agree that the proposed replacement is terrible. I'd suggest files are a great example for people who have a programming background because you can quickly show problems (e.g. streams considered as a subclass of files) that entail the kinds of tradeoffs and decisions the author rightly points out are shortcomings of the duck example (most of the shortcomings listed are in fact more a case of the author trying to show off and not problems with the example at all). But, you know what, duck, bird, and penguin are actually just fine. As the author himself (I assume it's a him) points out, penguins can't fly. And let's say that over hear we're doing vehicle, car, plane, and helicopter. How can we avoid implementing flying twice? And is it a good idea to treat flying like a plane, a helicopter, and a bird (but not a penguin) as the same thing. Oh, and the way penguins swim is amazingly analogous to flying, how can we leverage that? So, bye bye shitty drum machine example. I'm going back to duck and bird.

Wilduck 15y ago
As someone who is only a couple years past my first encounter with car/vehicle, duck/bird examples I can say that they did nothing useful for me. I think the reason they were so useless is not because they were trivially simple, but because they emphasize the wrong type of focus when dealing with inheritance. Presenting inheritance in terms of duck/bird emphasizes thinking in terms of similarities between nouns, which is misleading. I would have much rather seen some contrived example which does something other than print "quack". This, however, is a criticism with most tutorials that I've read. Most would benefit from having more substantive examples and letting the syntax and concepts fall out of them.
- podperson 15y ago
  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.