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

81–90 of 134 posts

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

#81

Post by sassafras »

fleitz wrote: post #80
sassafras wrote: post #77

Earlier quoted context omitted.

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.

Well, take this Clojure tutorial, for instance, comparing a simple DI implementation in Java with a single function in Clojure. The latter bears almost no resemblance to the former, other than achieving the desired effect. Is it fair to say that the user of a closure is implementing the Dependency Injection pattern, or is it a positive side effect of the fundamental properties of first class functions and lexical scope?

http://vimeo.com/10368175

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

#82

Post by 5hoom »

One of the first examples of OOP I encountered was the old 'shape' hierarchy demonstration: 'shape' is a base class. 'rectangle' is a new class that inherits from shape. 'square' inherits from 'rectangle', etc.

It demonstrates the ".. is a .." relationship that inheritance describes perfectly.

This is a pretty common way to introduce OOP as it draws on stuff we all know intuitively. The example proposed with a bunch of drum machines concepts, trash, timers & stripes or whatever is so mind bogglingly obscure for most people that I'm sure they would have checked out long before the actual OOP lesson begins.

Not sure what the point is.

Oh, and btw, just because you might not ever need to represent a 'duck' object, doesn't mean that it is a stupid example. Say I write a game with a bunch of actors, I might have a base actor class, a bird class that extends that, and a duck class that extends that. Bam, legitimate use for a 'duck' object. There's probably a lot more people wanting to write "a clone of the sims" than "an intractably obscure drum-machine".

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

#83

Post by jerf »

gruseom wrote: post #78
jerf wrote: post #67

Earlier quoted context omitted.

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

"The art of domain modeling is making those representations intelligible in domain terms. This has nothing to do with physicality."

Yes, exactly. I do love how often people cite back my own points at me as if they are disagreeing.

I think perhaps people have forgotten the origins of OO. A lot of people were taught that the right way to do OO is to match the physical model of the domain they are trying to program for. It's great that you and so many other people have either thoroughly internalized how untrue that is, or were never taught that model in the first place. But I for one was, as were a great deal of the rest of my generation who learned about OO in the 90s, and it's actually somewhat important that we finish stomping the idea out that physical mapping is at all an important aspect of OO.

And the best place to stomp it out of is in the Standard OO Tutorial (TM).

If you and all the excited downmodders never learned that bad idea in the first place, great! Count yourselves amongst the lucky people who probably also never had to be broken of things like line numbering, or two-letter variable names. (If you think I'm joking, I only wish I could show you some of the first-C++-class homework I graded back in 2000. I'm not joking.) In the meantime, this is a real thing that is still floating around in real curricula today, and you may join me in boggling at this fact, but it doesn't change its truth.

It actually stuns me that some of employees that we've hired who graduated as recently as last year appear to have received the exact same OO education that I did in 1999, which was already pretty creaky then.

The map is not the territory.

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

#85

Post by kragen »

5hoom wrote: post #82

One of the first examples of OOP I encountered was the old 'shape' hierarchy demonstration: 'shape' is a base class. 'rectangle' is a new class that inherits from shape. 'square' inherits from 'rectangle', etc. It demonstrates the ".. is a .." relationship that inheritance describes perfectly. This is a pretty common way to introduce OOP as it draws on stuff we all know intuitively. The example proposed with a bunch…

> 'square' inherits from 'rectangle', etc. ... It demonstrates the ".. is a .." relationship that inheritance describes perfectly.

Your comment is a perfect example of why this is a terrible way to teach object-oriented design: if your squares and rectangles are mutable, as they usually are in the old shape-hierarchy demonstration, you've just violated the LSP and introduced a subtle bug into your program, in the very first line of your comment. If you understood object-oriented design, you wouldn't do that. You've been tricked into thinking you know how to do object-oriented design, but your sense of competence is an illusion.

For what it's worth, although I don't have any real experience teaching other people to program, I've found that animated graphics that make sounds hold the attention of nontechnical people a lot better than abstract hierarchies of Platonic geometric shapes. I haven't compared them with bird-flocking simulations.

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

#86

Post by bendmorris »

This is ridiculous. I'm teaching part of a course called "programming for biologists" this fall including the part about object oriented programming. Most of my students are ecology grad students. You're telling me I shouldn't use simple animal examples, when these are exactly the types of things my students are going to be modeling?

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

#87

Post by kragen »

BenoitEssiambre wrote: post #79

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.

It's true that it's fairly infrequent, but it doesn't follow that it doesn't matter if a language makes it easier. When it's applicable, it simplifies things enormously.

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

#88

Post by TeMPOraL »

BenoitEssiambre wrote: post #79

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.

It is frequent in some applications, and when programming in languages that encourage you to recur instead of looping (see: functional proramming). Also, recursion is one of the most important concepts of computer science.

I didn't really use recursion in my programming until I switched from C++ to Common Lisp.

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

#89

Post by rbranson »

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?

Perhaps they are scanner & printer drivers, the implementation exposes a ScannerDriver interface and a PrinterDriver interfaces. They subclass a DeviceDriver that implements the low-level I/O. There are other generic and vendor-specific interfaces that could be used here, as well as perhaps some kind of more specific class on top of DeviceDriver like PCLDriver or PostScriptDriver.

class HPDriver extends DeviceDriver implements ScannerDriver, PrinterDriver

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

#90

Post by JulianMorrison »

Inheritance. Gah, why won't this bad idea die!

Shared calling protocol, shared data sub-structures, fixed compile-time equivalence hierarchy, all clumped together.

Go gets it right. Cut the linkage between composition and equivalence. Composition handles inclusion/merging of existing objects. Interfaces handle equivalence of objects. Interfaces can have hierarchies, but there's no one true hierarchy baked into the objects they describe.

Post reply on HN