Hacker News Reader

Comment by mikestew | Hacker News Reader

How about: if you're peddling software design advice, take some time to make (or find) a realistic example so I don't have to imagine so hard.

Somewhere around 1989 I swore that the next author of an OOP book that used animals as class examples was going to get an angry personal visit from me.

"Suppose you have an Animal class. We subclass to a Cat, and add a Meow method..." If it wasn't animals, it was cars: "we'll subclass Car to create a Ford class, add a Horn property..."

Because Customer/Vendor/Invoice was too commonplace? Between Customer classes and Animal classes, I'll give you a hint as to which I've created more instances of.

View on HN

Oh! You're a software developer at the local zoo too?

Humming birds, I tell ya thank goodness for multiple inheritance! I was able to inherit from both birds and bees. It saved me a ton of work. There was the time I used the flying mixin on sharks though, that was such a mess to cleanup.

I'm no expert at OOP, but never have I seen a student who telegraphs a look of comprehension after seeing an example of classes involving animals. I've seen many who get more confused.

Classes are a neat way of hiding implementation detail behind a mini-api that has reasonable code-hygiene benefits and works well in a team setting. None of these things have anything in common with meowing cats.

There was a classic on HN a while ago [1] illustrating how blindly guessing an OOP hierarchy for a problem isn't going to help. Throw that at a learner without thinking too hard, and they are going to question what the benefits of OOP even are - it doesn't always simplify a problem.

[1] https://www.quora.com/Is-abstraction-overrated-in-programmin...

HN thread: https://news.ycombinator.com/item?id=16047497

Mm. For me there are only a few reasons to use inheritance:

- Common operations between classes, operating on common data, but requiring an external API (so composition is a pain because you would have to proxy those actions to the member.)

- Restricting/specifying the types of objects you can store in a container if you are programming in a language/codebase that cares about that (incl. the C++ "definitely has the vtable I want".)

And maybe that's it? I guess all the taxonomy talk might be useful in the first hour of learning about inheritance, but after that I think the analogy should give way to more concrete "what are the code and data doing?" angle.

I agree. Inheritence is useful in a very small amount of situations and can be the start of a long abstract chain of bullshit if other devs are allowed to build more funtionality on top...

I’ve only ever seen inheritance make sense in UI toolkits. That’s literally it.

It’s like if someone took the cascading idea of CSS and decided “this works so well for UI styling, let’s build a language paradigm out of it and convince people they need to express every problem in terms of it.”

> never have I seen a student who telegraphs a look of comprehension after seeing an example of classes involving animals

I think it's a classic case of teaching people the answer before the question.

Animal examples explain what types and subtypes are, but the thing that warrants explaining is why and when it's useful to separate things into types and subtypes, and animal examples are terrible for that. If someone asks "should Cat and Dog inherit from Quadruped? Mammal? Pet?" there's no useful answer.

> Because Customer/Vendor/Invoice was too commonplace?

I don't know which I hate more. Animals and cars, or this. And don't get me started on portfolios and stocks.

Some of us learned programming having absolutely zero clue what an invoice is. Hell, I remember being sad that all this fun knowledge is introduced with these weird, boring examples from bankers' world, as if written for PHBs.

The point is, I guess, no examples are ideal. That said, animal examples probably deserve a special place in hell, as they mess up not just with your understanding of OOP, but also biology.

Once I learned about Unix, I felt that IO devices would make a better example of class inheritance. You have a base abstract class. From that, you get a block device (seekable devices with fixed-sized blocks), a character device (say, a serial port, or a keyboard), a variableblock device (like a tape drive or network, with variable sized blocks that may or may not be seekable). And then you can subclass from there. A more or less realistic example.

Reply on news.ycombinator.com