Goodbye, shitty "Car extends Vehicle" object-orientation tutorial

Post by spc476 » Tue, Aug 23, 2011, 6:01 AM UTC

kragen wrote: post #42

d0m wrote: post #7

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…

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…

Post by riffraff » Tue, Aug 23, 2011, 6:10 AM UTC

kragen wrote: post #42

d0m wrote: post #7

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…

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…

Post by dtreacy » Tue, Aug 23, 2011, 6:47 AM UTC

Post by haberman » Tue, Aug 23, 2011, 7:25 AM UTC

barrkel wrote: post #43

enjalot wrote: post #38

Earlier quoted context omitted.

I think the point is more that the analogy is so misleading, that it hurts the student's understanding. A similar bad example would be using familiar round objects to teach equivalence: there are 10 apples, and 10 oranges, so apples == oranges. Car's don't extend vehicles, and duck's don't extend birds. Just because we can organize these physical things into conceptual hierarchies based on their functionality, doesn'…

There is a direct mapping between our natural construction of ontologies (we are pattern-detecting creatures, we naturally see commonalities across the birds) and why object orientation works. Cars are a subset of vehicles in most peoples' minds; and Buttons are a subset of Controls in most UI programmers' minds. And the topologies of these ontologies are similar enough, by design , that you can indeed teach valuable…

Post by Markku » Tue, Aug 23, 2011, 7:33 AM UTC

haberman wrote: post #6

jeffreymcmanus wrote: post #2

> You can’t add code to ducks. You do if you are creating a piece of software to track ducks. I don't get the impression that the person who wrote this ever had to seriously teach software development to software developers. Simplistic metaphors are used so frequently for this kind of thing because it prevents the learner from having to ascend more than one conceptual hurdle at a time. The alternative that he's propo…

You can explain is-a using examples that actually make sense to model using inheritance, like a set of game objects that have an interface like: class GameObject { public: // Called every frame to update the object's logical state. void Update(GameState* state); // Called to draw the object. Draw(GraphicsContext* context); } class EnemySpaceship : public GameObject { /* ... */ }; class SpaceDebris : public GameObject…