Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lists.canonical.org

Post reply on HN
Print view View original

101–110 of 134 posts

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

#101

Post by pbhjpbhj »

jerf wrote: post #19
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…

His point is that you can't add code to ducks... full stop. If you want to talk about "software [that] tracks ducks", then do so, but by talking about physical ducks one further encourages the ancient fallacy that object orientation is about physical modeling and should be all about physical objects and their physical relationships. What was said was what was meant; you can not add code to ducks . They shouldn't be i…

>you can not add code to ducks //

[I'm in a bit over my head but] Sure you can. This is just the sort of thing that happens in such tutorials - "now lets make all our ducks say moo if they're speaking but on land at the time".

When I learnt OO we used frogs, in SmallTalk, as our analogy. I don't think I ever once thought that the "frog" was in some way limited to things frogs could do, only that it was representing a series of things with a particular relationship wherein those things could have different characteristics and behaviours.

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

#102

Post by bjoernbu »

The example for inheritence I liked best was something like this:

Number (implementing trivial exponentiation through multiplication)

RealNumber & ComplexNumber implementing their specific kind of multiplication.

Later on replace the exponentiation by fast exponentiation. This directly demonstrates the benefits of avoiding code duplication.The change only has to be made in one place.

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

#103

Post by wlievens »

barrkel wrote: post #44
MatthewPhillips wrote: post #28

Earlier quoted context omitted.

True, but I still don't think this is a good analogy. When you are learning inheritance you don't know what "x extends y" even means. Using a non-code example obscures what you are talking about. I'd use an example like this: HPDriver extends PrinterDriver. CanonDriver extends PrinterDriver. EpsonDriver extends PrinterDriver. See, you can make 3 different drivers and share common printer code. That makes sense to me…

I'd object to your example: your example seems to me to be closer to that of instance :: class than subclass :: superclass. PrinterDriver defines a contract; each of HPDriver, CanonDriver etc. will need to fulfill the contract. But I don't see them usefully adding behaviour. The OS would have to already know about HPDriver in order to use its extra functionality - then what's the point in using inheritance at all?

I don't understand how a driver implementation is an instance. I can imagine the HPDriver class having completely different code than the CanonDriver class.

For a realistic version of this example, consider JDBC driver implementations.

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

#104

Post by wlievens »

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…

My nitpick about EnemySpaceship: whether an entity is enemy or not should not be part of its type but part of its state and/or logic.

I know it's "just an example" but to me this thread is about whether arguably incorrect examples are bad practice or not.

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

#105

Post by wlievens »

fleitz wrote: post #10
haberman wrote: post #6

Earlier quoted context omitted.

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…

Most of the benefits of OO programming come from abstracting the machine / concerns (eg. MVC) rather than modeling the domain. (eg. Cars / Ducks / etc). I know it's just an example but it raises several important questions: Why does the GameObject need to know how to render itself? Why does the GameObject update the GameState which the GameObject is ostensibly also a part of? Does updating the GameState directly affe…

Modeling a domain right is deceptively hard, and to me is one of the primary skills of our profession. Teaching what OO and inheritance mean is not the same thing as modeling a domain.

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

#106

Post by wlievens »

fleitz wrote: post #53
haberman wrote: post #49

Earlier quoted context omitted.

Yes, because drawing a bunch of game objects on a screen is something a real program might actually want to do, and therefore opens up opportunities to talk about real-world design tradeoffs. Making a program print "quack" when you call the "speak()" method is something that only happens in textbooks, and since there's no reason to actually do that there's no easy way to discuss the alternatives and why polymorphism…

So what you're saying is that Farmville is the ultimate result of reading OO textbooks, and that if they had spent more time on a realistic model such as spaceships and gameobjects that a game such as Knights of the Old Republic could be produced by Zynga?

That has nothing to do with what haberman is saying. Most people know games, and a simple game model can be expressed in inheritance terms in such a way that's illustrative and less contrived than conventional tutorial metaphors. And I agree with that.

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

#107

Post by wlievens »

azov wrote: post #37
SingleShot wrote: post #35

I disagree with the arguments in general and find that modeling real world, common items is much more illuminating from a teaching/learning point of view. It would be an ridiculously long post to explain why, but here is an example picking one of the author's bullet points: "Penguins don’t implement the fly method that can be found in birds." Should bird even have a fly method? Only if all birds fly. And the applicat…

Indeed. The example with Birds, Ducks, and Penguins is much more colorful and fun then example with GUI widgets. It sticks. Students will remember ducks & penguins, but fall asleep before you even finish describing that boring GUI system. Plus, nothing prevents you from using the same fun example to illustrate the second point. E.g. you can show that while penguin is a bird in real world, in your application Penguin…

If a CS student falls asleep when you talk about GUI systems, they're not in the right class.

I didn't need fluffy birds and colorful metaphors to get into this passion of mine.

The audience doesn't deserve to be patronized like that.

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

#108

Post by barrkel »

haberman wrote: post #97
barrkel wrote: post #43

Earlier quoted context omitted.

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…

Object-orientation does not work because cars are a subset of vehicles. Please do not teach anyone that. Object-orientation works because in some programs, cars can be treated as if they were a vehicle, without knowing what kind of vehicle it is. This is the principle of substitutability , and it's the actual reason that inheritance hierarchies work. But in other programs, cars and other vehicles may not have much in…

I think you missed my point. The real-world ontology doesn't exist; it's only in our heads. The mechanisms in our heads for these ontologies are what OO uses and why it works for humans.

The point is the commonality of mechanism, not the commonality of any specific ontology. And when you're teaching, that's enough for one lesson.

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

#109

Post by wlievens »

In my experience, there's a process where adding accuracy (and thus usually complexity) to a domain model, implies removing existing inheritance assumptions.

For instance, in the trivial case an Employee is a Person, but when you go further you discover that there are all sorts of relations that need more detailed fleshing out. Is changing jobs just a call to Employee.setEmployer? That certainly feels akward. And as that process continues, you get a more complex domain model with comparatively less fixed inheritance relations.

The extends keyword sortof becomes an extend object, first-class among your domain and susceptible to dynamic behaviour.

But can you teach kids that in a first OO class?

EDIT: care to explain the downvote? I'm quite passionate about this subject so would love to debate it.

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

#110

Post by JonoW »

haberman wrote: post #8
mattdeboard wrote: post #4

Earlier quoted context omitted.

I agree without caveats. "Car extends vehicle" and "duck extends bird" are great examples for the type of lesson they're trying to teach. I'm surprised people have time in their lives to worry about this crap. edit: Also, what's up with the title for this submission?

If it teaches people to think of object-oriented programming as world-modeling, it is not a great lesson. Polymorphism is an abstraction technique whose goal is substitutability . "Car extends Vehicle" is useful if other kinds of Vehicles can be substituted for cars. If you teach someone that there is value in making Car extend Vehicle just because that expresses a real-world relationship, you are teaching exactly th…

> Polymorphism is an abstraction technique whose goal is substitutability

If you said that to students in lesson #1 of an OOP course no one will understand what you're talking about.

Sure maybe the Duck extends Animal example isn't a realistic one, but you've got to give students a chance to get their heads around the very basics first, and they can at least understand it by using simple real-life things.

Post reply on HN