"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.
> 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.
>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.
Yes, you're right, it's only a great lesson if it's taught properly. I mean, really? Doesn't that seem like hair-splitting to you?
In my opinion, dickering about this is the equivalent of, "Yeah, those two hortizontal parallel lines are a great symbol for equality as far as it goes, but really students need to understand the difference between equivalence and implication!" It's an equals sign.
Same deal here. It's an analogy. The fact that analogies must be taught properly to be useful is a tautology that doesn't even bear mentioning, yet here we are.
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't mean we can use them to understand polymorphism.
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 lessons using vehicles and birds.
As to polymorphism, that comes for free from understanding language. Most people will understand a "No vehicles allowed" sign to prohibit cars but not people. What else is that but an understanding of polymorphism in evaluating a predicate?
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 common and should not be part of an inheritance hierarchy!
The real-world ontology is not a reason in and of itself to create an inheritance relationship.
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.
No, it's not misleading. It is insufficient to capture the totality of what is meant by object-oriented programming and polymorphism. But it is not misleading. It is simply a very narrowly applicable -- but very useful, when leveraged properly -- analogy.
Polymorphism is an abstraction technique whose goal is substitutability. "Car extends Vehicle" is useful if other kinds of Vehicles can be substituted for cars.
"That's great", thinks the student, "I'll keep that in mind on the offchance I ever need to write code for an automatic carwash..."
Honestly I think these examples are fine as far as they go, but they should be immediately followed up with nontrivial examples demonstrating how you might actually use this in programming problems which don't fall into the category "simulation of real-world objects". Otherwise the student can easily dismiss the whole idea as esoteric.
I worry about it because I learned inheritance from using it. I wish I had learned from a teacher. Instead I made hack work-arounds for something that I didn't realize was a common feature of OO languages. Until one day I did some poking and said "oh, THAT'S what extends and implements is for!"
"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?