Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
lists.canonical.org
Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
1–10 of 134 posts
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#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 proposing (learning inheritance in terms of some obscure drum machine software) would imply that the learner spend half their time digesting how this drum machine works, then the rest of their time (assuming they're still awake) figuring out how that relates to inheritance. It isn't helpful.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#3> 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…
I agree, but he gets to a much simpler, teachable example near the end, which is representing shapes. Mathematically, a circle is an ellipse, and an ellipse is a polygon. It's much cleaner than the biology or work-place inspired taxonomy. A simple drawing program can feel less contrived, but, then again, so can simple games that use an object hierarchy unrelated to polygons.
Fundamentally, though, I do agree with your point. You don't use completely realistic examples to teach concepts for the fist time. All of the incidental material that is necessary to grok the example clouds the new concepts. Sometimes this means the examples will be pedagogical toys, and that's okay. The benefit of the already known taxonomies is that the student has less to learn. The new concept is more obvious. If the worry is that the example is too much like a toy, then address that in the second example. In general, I think people put too much emphasis on first exposure to concepts. Education is iteration. If it doesn't take the first time, there are more tries coming up.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#4> 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…
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?
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#5Is Kragen making an elaborate joke about duck typing here?
Penguins don’t implement the “fly” method that can be found in birds. And you don’t go around causing things to fly without knowing what kind of bird they are. (Ducks themselves decide when they want to fly, and they certainly seem to know they’re ducks and not vultures.)
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#6> 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 { /* ... */ };
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#7Heh, 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.
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."
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#8> 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…
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 the wrong lesson and your students will create overly complex inheritance hierarchies.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#9> 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…
Is "Spaceship extends GameObject" really that different than "Duck extends Animal"?
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#10> 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…
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 affect the ability to separate concerns as to whether the GameState being modified is local vs. remote?
When you start modeling domains it leads very easily to situations where you have hardcoded permissions for the Manager class instead of bothering to implement a permissions system. Or you have a CEO class that's a singleton. (Hopefully, your code doesn't have to work at RIM)
The code savings from
class DeathStar2 : DeathStar {
public override FatalFlaw(){}
}
class DeathStar2 : Object {
acts_as_travelling_salesman
has_many :laser_turrets, :max => 1024
has_many :tie_fighters, :max => 2048
}