I actually think these are really good examples. I especially like the shape example, because you quickly run into problems where you can talk about the difference between modeling for a solution and representing an abstraction.
Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
11–20 of 134 posts
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#12The only situation where I could see not wanting to hear the car extends vehicle example of inheritance is in an interview where you want the candidate to give a practical example of inheritance. I see nothing wrong with using an example even a child could understand as a first stab at explaining inheritance.
Fairly annoying how quickly a mostly useless rant such as this has jumped to the top of HN.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#13> 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 you…
> 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.
Well, the circle-ellipse problem complicates that example a little bit: http://en.wikipedia.org/wiki/Circle-ellipse_problem.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#14Depends 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.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#15"Car extends Vehicle" is a perfectly fine example to introduce someone to OO programming. That's all.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#16> 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…
>rather than to make it a pointless ontological exercise of whether a Square is-a Rectangle or vice-versa
it isn't pointless. It is the key point of the design : http://www.objectmentor.com/resources/articles/lsp.pdf
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#17I completely agree with this. Duck-laden object oriented programming tutorials made no sense as I tried to transition from C to Objective-C.
The best explanation I found was Chapter 2 of Apple's "Object-Oriented Programming with Objective-C":
Every object has both state (data) and behavior (operations on data). In that, they’re not much different from ordinary physical objects. It’s easy to see how a mechanical device, such as a pocket watch or a piano, embodies both state and behavior.
http://developer.apple.com/library/mac/documentation/cocoa/c...
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#18[deleted]
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#19> 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 in the tutorial at all, just as Chevrolets shouldn't be.
Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial
#20Way 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 still doesn't apply.
I think a simple example from GUI programming would do much better. How about window classes? I did something like this recently:
class Window {
public method show()
public method title(newTitle)
public method close()
}
public class ModalWindow extends Window {
public method show()
public method close()
}