Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lists.canonical.org

Post reply on HN
Print view View original

71–80 of 134 posts

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

#71

Post by kragen »

sassafras wrote: post #66
jerf wrote: post #19

Earlier quoted context omitted.

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…

You can't add code to ducks any more than you can add code to sockets. Let's assume for a moment the hypothetical student in this scenario is bright enough to tell the difference between literally describing a thing, and expressing an abstraction of it. So basically then, the thing we're all supposedly getting in a kerfluffle about is that the example program in a hypothetical textbook that introduces the concept of…

If someone is actually writing about a bird-flock simulator or something, I think Duck is a perfectly fine example. My beef is with Duck being presented in the abstract, disembodied.

> concepts such as Dependency Injection, which was the meat of the grandfather rant, are IMHO more an outgrowth of dealing with the limitations of OO design...

I don't think so. The inflexibility you can loosen with DI exists in all kinds of non-OO and even non-imperative programs as well. In a sense, the whole point of object-orientation is that it gives you a handle on that kind of thing: the thing you depend on is an object reified at run-time, which you can arrange to have passed in to you instead of extracted from a global namespace, and which can be replaced with some other object with different behavior, not an address you are jumping to that's hard-coded into your compiled jump instruction as an immediate argument.

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

#72

Post by sethg »

barrkel wrote: post #44
MatthewPhillips wrote: post #28

Earlier quoted context omitted.

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…

I'd object to your example: your example seems to me to be closer to that of instance :: class than subclass :: superclass. PrinterDriver defines a contract; each of HPDriver, CanonDriver etc. will need to fulfill the contract. But I don't see them usefully adding behaviour. The OS would have to already know about HPDriver in order to use its extra functionality - then what's the point in using inheritance at all?

Different printer models could have different features (color/B&W, selecting output tray, “print” an outgoing fax, etc.), and you could make each PrinterDriver subclass responsible for generating the appropriate UI code for frobbing those features.

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

#73

Post by kragen »

georgefox wrote: post #13
scott_s wrote: post #3

Earlier quoted context omitted.

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 .

The circle-ellipse problem almost never arises in real software, in my experience. It's not in the same league as the Fragile Base Class problem, or the Diamond Inheritance Problem, or the Schema Upgrade Problem, or the Ravioli Code Problem, or the problem of poor performance caused by too many layers of abstraction, or the Big Ball Of Mud Anti-Pattern. It's essentially a thought experiment.

What does it teach us? Well, one lesson is that you can't design good inheritance hierarchies in your program simply by aping ontological relationships in a Platonic Ideal World, which is the main point of my article. Another lesson is that sometimes you'll discover that your program is inadvertently violating LSP because of some nonobvious interaction, and that this is a bug, and you need to fix it. A third lesson is that mutability is tricky, in particular with respect to the Liskov subtyping relation; this same problem comes up in non-OO contexts as well, if you have mutability and any kind of subtyping relation. (OCaml polymorphic variants, for example, create a subtyping relation all by themselves, even without OCaml's OO features, and that's enough to create the problem.)

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

#74

Post by kragen »

haberman wrote: post #6
jeffreymcmanus wrote: post #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 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…

This is in fact more or less the example I suggest using in the article, except that the objects don't have a separate update method.

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

#75

Post by cema »

1. I absolutely agree with the linked article. My perspective is somewhat different, however. I submit that OO hierarchy should not mimic whatever properties whatever real-world objects may happen to possess. Instead, when we solve a problem and have come up with a solution, the OO hierarchy should describe the solution. A different solution, or a different problem, may easily lead to a different hierarchy of (perhaps different) objects. And these would be software objects.

2. Therefore, I suggest that a "simple" example would come from a well-known software system. Such as a window system (rectangle, button, icon, window, etc) which, either as a concrete example or an abstraction, should be easily understood by anyone with a minimal (desktop) computer experience and no programming experience.

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

#76

Post by kragen »

georgieporgie wrote: post #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 becau…

I appreciate your disagreement, and I might be wrong. My concern with those examples is not that they're trivial but that they're misleading.

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

#77

Post by sassafras »

kragen wrote: post #71
sassafras wrote: post #66

Earlier quoted context omitted.

You can't add code to ducks any more than you can add code to sockets. Let's assume for a moment the hypothetical student in this scenario is bright enough to tell the difference between literally describing a thing, and expressing an abstraction of it. So basically then, the thing we're all supposedly getting in a kerfluffle about is that the example program in a hypothetical textbook that introduces the concept of…

If someone is actually writing about a bird-flock simulator or something, I think Duck is a perfectly fine example. My beef is with Duck being presented in the abstract, disembodied. > concepts such as Dependency Injection, which was the meat of the grandfather rant, are IMHO more an outgrowth of dealing with the limitations of OO design... I don't think so. The inflexibility you can loosen with DI exists in all kind…

Interesting. I suppose when I think of DI I usually think of Java. Do you know of a good example of the DI pattern being used in functional languages?

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

#78

Post by gruseom »

jerf wrote: post #67
gruseom wrote: post #64

Earlier quoted context omitted.

So domain modeling has no place in software? The burden of proof for such a claim is a bit higher than "you can't add code to ducks". That ducks are physical is irrelevant in any case. You can't add code to bank accounts or insurance policies or leap years either.

"You can't add code to payrolls or insurance policies or bank accounts either." No... you can't. Exactly. OO isn't about real-world-objects, it's still about code-objects, and mixing the two up causes serious category errors. Physical modeling is the wrong way to do it, it's the wrong way to teach it, it's the wrong way to conceptualize it, it should not be used in tutorials. Domain modeling != physical modeling, and…

I don't get what you're saying. What does it matter whether software is modeling a physical system or, say, a business one? Either way you're drawing on concepts from some domain that exists prior to the software you're building. Either way you're trying to find representations of those concepts suitable for computing what you need to compute. The art of domain modeling is making those representations intelligible in domain terms. This has nothing to do with physicality. Of Evans' canonical examples in Domain Driven Design, one has to do with paint-mixing and another with accounting. The techniques are no different.

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

#79

Post by BenoitEssiambre »

I would also add. Don't introduce a language by showing how to compute the Fibonacci sequence.

I never have and never will need to compute the Fibonacci sequence. Recursion is such an infrequent part of everyday programming that it doesn't really matter if a language makes it easier.

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

#80

Post by fleitz »

sassafras wrote: post #77
kragen wrote: post #71

Earlier quoted context omitted.

If someone is actually writing about a bird-flock simulator or something, I think Duck is a perfectly fine example. My beef is with Duck being presented in the abstract, disembodied. > concepts such as Dependency Injection, which was the meat of the grandfather rant, are IMHO more an outgrowth of dealing with the limitations of OO design... I don't think so. The inflexibility you can loosen with DI exists in all kind…

Interesting. I suppose when I think of DI I usually think of Java. Do you know of a good example of the DI pattern being used in functional languages?

map and reduce. DI is so prevalent in functional programming that it's pretty much taken for granted.
Post reply on HN