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

121–130 of 134 posts

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

#121

Post by Wilduck »

podperson wrote: post #117
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…

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 sh…

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.

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

#122

Post by CodeMage »

The problem people have with "Car extends Vehicle" is that they expect magic. It's the same impatience we sometimes feel with little kids because they're not grasping something we've been taking for granted for decades. If you're trying to teach someone new to OOP, there is no example that will take them from their current level of knowledge to yours, in one fell swoop. You can't expect them to grapple with decisions such as "inheritance vs. delegation" when they're only now learning what inheritance is all about.

So yeah, "Car extends Vehicle" and "Duck extends Bird" works pretty well at that point. You can try to cram "Penguin" and "Helicopter" and "Flyer" and "Vehicle" down your students' throats in the same lesson, but I doubt that will magically make them digest it properly. And if you can't do that with easy stuff like "Duck" and "Bird", how do you expect them to swallow "NumericHalo" and "ImageDisplay"?

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

#123

Post by marshray »

jerf wrote: post #63
marshray wrote: post #58

Earlier quoted context omitted.

A lot of OO was, in fact, influenced by the task of writing programs for simulations. It's conceivable someone might actually want to develop animal/bird/duck classes (e.g., SimAnimals). http://en.wikipedia.org/wiki/Simula

Yes, I know. That's where the idea came from. Nevertheless, it's a terrible introduction to OO. It promotes very wrong conceptualizations and horrible code. And odds are, even if that is the type of code you're writing, you still shouldn't be trying to have a one-to-one mapping between physical things and classes and/or instances. It just isn't a very good way to work. Just because it was the first thing that was don…

There are lots of ways to structure programs, and talk about how programs are structured. Some are good for some programs, others are good for others.

Knowing when to use which metamodel is an art that is only learned after long experience.

A lot of this discussion about the inherent superiority of spaceships to ducks seems to reflect the familiarity bias of the participants as much as anything else. There are certainly interesting points being made here, but maybe game experience isn't as ubiquitous as some seem to think.

On the other hand, maybe game developers could learn a thing or two about ducks. In Minecraft, for instance, they cluck like chickens.

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

#124

Post by TheCapn »

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…

>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 the wrong lesson and your students will create overly complex inheritance hierarchies.

Only if your students are idiot drones. I think the majority of us went through these same lessons and came out just fine. Stupid is as stupid does (why do I keep saying that so much?) People who are good programmers can take a simplistic lesson like that and grasp the over-all concepts while people destined for terrible careers simply wont. No point bringing down the rest us with them.

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

#125

Post by oconnor0 »

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…

Do you have an example of modeling concerns vs. modeling domains?

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

#126

Post by podperson »

Wilduck wrote: post #121
podperson wrote: post #117

Earlier quoted context omitted.

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 sh…

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, whic…

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.

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

#127

Post by gruseom »

jerf wrote: post #83
gruseom wrote: post #78

Earlier quoted context omitted.

I don't get what you're saying. What does it matter whether software is modeling a physical system or, say, a business one? Either way you're drawing on concepts from some domain that exists prior to the software you're building. Either way you're trying to find representations of those concepts suitable for computing what you need to compute. The art of domain modeling is making those representations intelligible in…

"The art of domain modeling is making those representations intelligible in domain terms. This has nothing to do with physicality." Yes, exactly. I do love how often people cite back my own points at me as if they are disagreeing. I think perhaps people have forgotten the origins of OO. A lot of people were taught that the right way to do OO is to match the physical model of the domain they are trying to program for.…

"I do love how often people cite back my own points at me as if they are disagreeing."

For what it's worth, when I read that I found it unpleasant in more ways than one and it killed my interest in further discussion. Perhaps that was for the best, as I didn't seem to be making any progress in understanding you.

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

#128

Post by Wilduck »

podperson wrote: post #126
Wilduck wrote: post #121

Earlier quoted context omitted.

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, whic…

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 stu…

>> 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.

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

#129

Post by fleitz »

sassafras wrote: post #81
fleitz wrote: post #80

Earlier quoted context omitted.

map and reduce. DI is so prevalent in functional programming that it's pretty much taken for granted.

Well, take this Clojure tutorial, for instance, comparing a simple DI implementation in Java with a single function in Clojure. The latter bears almost no resemblance to the former, other than achieving the desired effect. Is it fair to say that the user of a closure is implementing the Dependency Injection pattern, or is it a positive side effect of the fundamental properties of first class functions and lexical sco…

IMHO it's largely a side effect of first class functions. In Java in order to pass a function you need to pass an object that has the function, or an interface with the function, so it leads to a lot of line noise and thus people don't do it much. DI doesn't look impressive in a functional language because it's so well supported, but if you look at something like a global accumulator in a functional language you'll need a monad because you need state.

eg in Java it's easier to write:

  int accum = 0;
  for(int i : collection){
    accum +=i;
  }
rather than

  collection.reduce(new IReduce { 
    int reduce(int accum, int i){
      return i + accum;
    }
    })
I'm a bit rusty on Java so the syntax may be off but you get the idea, where as in a functional language (F#) that code is reduced to:

  collection 
  |> Seq.reduce +
Or in an imperative language that supports function passing (C#)

  collection.sum((a,b) => a+b)

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

#130

Post by fleitz »

oconnor0 wrote: post #125
fleitz wrote: post #10

Earlier quoted context omitted.

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…

Do you have an example of modeling concerns vs. modeling domains?

Lets say you're modeling a system with Customers and Salesmen both of which are Persons, should you put that travelling salesman algorithm into the Salesman class or the Person class? That's what I mean by modeling domains.

By modeling concerns I mean that you should create a RouteFinder class and an adapter that extracts the coordinates from Salesman, Persons, and Customers. Maybe there is a convenience method on the Salesman class that makes it easy for him to travel to his customers but most of the work (the concern) is modelled separately from the domain.

The primary concern of the program is routing, not Salesmen and Customers. It's like how rails/ASP.NET MVC/django concerns itself with making websites, not modeling domains. If you focus on the concerns the domain becomes an implementation detail. (eg. For the person class the coordinate can be found at Person.Address.Latitude)

Post reply on HN