51–60 of 134 posts
Use simple but realistic classes as examples.
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…
Is "Spaceship extends GameObject" really that different than "Duck extends Animal"?
"Spaceship extends GameObject" exists mostly to facilitate polymorphism and code reuse - virtual function resolution, probably, along with all of the non-virtual data and behaviour associated with every GameObject. A "GameObject" isn't a real thing, it's just a convenience.
Out of context, "Duck extends Animal" could obviously do the same things for the same reasons, but that's not really the point of the example. It's implied that the relationship was used because real ducks are real animals, not because Duck inheriting from Animal is a good idea.
Earlier quoted context omitted.
Is "Spaceship extends GameObject" really that different than "Duck extends Animal"?
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…
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…
Yeah, I guess if I learned OOP with Java I'd hate it too. I look at phrases like "public class ModalWindow extends Window" and am very thankful I started with Python (and have learned Java where necessary, mostly to support Clojure).
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 eschew inheritance except for when two objects or libraries are very much the same thing but the implementations are different. Just an example, where I might want to have the opportunity to use two different PDF libraries.
Further, there's a case where a number of objects share some common methods and you may decide to implement an AbstractWindow where those methods can live. But, you may find that Aspect programming works better in that case.
Generally, and perhaps surprisingly you shouldn't use inheritance in most cases. But inheritance is nonetheless a very important part of OOP.
Earlier quoted context omitted.
Is "Spaceship extends GameObject" really that different than "Duck extends Animal"?
When people say "Duck extends Animal" is bad they typically mean that it's trying to model real-world relationships rather than computational relationships. The example is meant to demonstrate that inheritance should be based on what inheritance means for your program, to make your codebase "nicer", and not to simply categorise your objects. "Spaceship extends GameObject" exists mostly to facilitate polymorphism and…
But don't try to convince any OO purists that inheritance "exists mostly to facilitate polymorphism and code reuse". :-)
"Car extends Vehicle" is a perfectly fine example to introduce someone to OO programming. That's all.
> 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…
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…
> ...my instructor told me that was wrong and that I didn't understand OOP...
Ugh.
I wonder how it should be taught then? Looking at the comments in this thread, it looks like a lot of people are simply choosing to use it in ways that make sense to them. Is there a universally-agreed-upon use case for OOP? If not, is there anything wrong with just teaching it as one of many tools, and letting students sort it out on their own?
I've tutored a few kids on programming. OOP has been my least favorite part every time. I honestly have no idea how to approach it as an occasional instructor.
Some people see no problem with Vehicle->Car or Animal->Duck or whatever other ultra basic OO example.
In the end what's best is whatever can make someone understand the concept.