Live data from Hacker News

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

lists.canonical.org

21–30 of 134 posts

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

#21
Just one piece in the whole object orientation blows but still is the best thing we have to make complex systems understandable to simple people quandary.

It is true that the real world object examples confuse everything that OO is really used for. It is also true that we need them to make OO approachable at all.

OO is essentially an ontological cluster-fck where multitudes of logical and representational levels are trampled on. The thing is, OO uses* the adhoc mixture of logical confusions that is most people's description of their world. Somehow people's amazing brains muddle through speaking natural language despite it's terrible muddling of everything. Thus we can stand the confusion of not really knowing whether "class window" is a glowy thing on the screen, a location in memory or an abstract datatype.

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

#23

Depends on the audience. If you're using the "Car : Vehicle" example, you're probably explaining the basics of OO to a newbie. I think that's a fine example. If you're talking about more advanced topics, then you can use a more advanced example. In fact, you can use different examples suited to different topics! Relax, there's no need to be a pedant.

Honestly, when I was a newbie, the simplistic examples drove me crazy because I didn't get the point. I can solve the toy problem effectively with concepts already introduced (functions) why am I burdening my code and my brain with all this new overhead?

The OP's suggestion to use a GUI interface is much better. GUI objects like windows are a common and interesting subject. Ironically, Object Oriented features in languages like Java and C# made a lot more sense to me after writing a Win32 gui app in straight C.

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

#24

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

Personally I'd add the code to "TrackedObject" rather than "Duck" just in case we ever wanted to track geese or cormorants.

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.

Perhaps, though I think his real point is that often folks teaching software development will only put out that first hurdle and forget about the rest. Teach 'em that "ducks are animals" and think they understand inheritance, when in fact these simple physical analogies are a bad way of understanding how and why you might use inheritance in the real world.

I think it's a phenomenon quite common across the whole OO pedagogy, in fact. If your only mental examples of "objects" are ducks and bicycles then you're going to get pretty confused when you escape simple example land and start trying to understand the difference between an NSView and an NSViewController.

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

#26
post #8

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

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

#27
If I understand correctly, this rant is about the use of simplistic examples in teaching OOP, correct? i.e. it's not just about using such examples when debating language features.

If so, then I very strongly disagree with this guy. I have painful memories of trying to come to grip with OO in high school in the early 90's. Sure, those zoological and automotive examples are almost insultingly trivial, but that's because you don't need real-world engineering complexity interfering when you're just trying to wrap your head around inheritance and extension!

Bird ==> Duck makes sense because they're classes. As in, those are classes of animals in the real world, and there is a relationship among them. Expressing that relationship in code doesn't mean you're coding animals, it means you're modeling a real-world class hierarchy with your data definition.

I think that people are forgetting that OOP is actually hard. If you don't already have a very strong grasp on the underlying mechanics of a language (e.g. function pointers and vtables in C++), then it's going to always seem like magic.

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

#28

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

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 if I'm just learning inheritance. Duck extends animal does not.

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

#29
post #8

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…

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.

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

#30

Way back when I was first learning OOP, the typical "car extends vehicle" examples caused me not to see the practical point of OOP for a long time. I still resist using object-oriented approaches except in cases where the code demands it. (A feature, not a bug?) And, these days, if I do use OOP in places in the code, it's for encapsulation -- which is only a style consideration -- so the "car extends vehicle" example…

I think a simple example from GUI programming would do much better. How about window classes?

It's funny, because OOP came my sphere of awareness around the same time that desktop software was beginning to use it for extensible GUIs. I'm talking about Turbo Pascal's Turbo Vision, and whatever Turbo C++ had.

That actually slowed down my comprehension of OOP. I thought OOP was for GUI work. OOP added so much complexity to the GUI code, and the GUI code added so much complexity to the OOP concepts, that it actually set me back by quite a bit! :-)

Mind you, it didn't help that, just as I was grasping crucial OOP concepts (e.g. a pointer to base class can point to an instance of child class), my instructor told me that was wrong and that I didn't understand OOP...

Post reply on HN