Hacker News Reader

Comment by Jach | Hacker News Reader

Fully agree, let's not go back to instinctively applying all of the patterns from GoF. I'd also like to quibble with just this:

> When reading software design advice, always imagine the examples given are 10x longer.

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. Even if it's in a toy-problem type of scenario the code can be realistic. Working Effectively With Legacy Code has spoiled me by setting such a higher standard than most peddlers, since it actually presents real code (sometimes 3 pages of it at once) in real languages (Java and C++) using styles and highlighting problems I actually see in legacy codebases with those languages, and how to address them.

View on HN

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.

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.

I've found Holub on Patterns to be a fantastic resource on applying GoF patterns to real world code.

Reply on news.ycombinator.com