Hacker News Reader

Comment by LordN00b | Hacker News Reader

Are you sure? His argument is one simple paragraph:

  The `Car extends Vehicle` or `Duck extends Bird` type of tutorial
  obscures more than it illuminates.  In good OO programming, we don’t
  make class hierarchies in order to satisfy our inner Linnaeus. We make
  class hierarchies in order to simplify the code by allowing different
  parts of it to be changed independently of each other, and to
  eliminate duplication (which comes to the same thing). Without any
  context as to what the code needs to accomplish, you can’t make a
  judgment about whether a particular design decision is good or bad.

View on HN

Agreed, it’s a really concise and clear articulation of one of the main traps of inheritance thinking.

I also think people are very receptive to this once you point it out. You’re not trying to make a class hierarchy because you come to the problem with a presupposed mental model. Instead you should be letting your attempt to solve the problem with no abstraction teach you about the places where abstraction would help. Maybe it should be organized as inheriting behaviors via mixins instead of specializing behaviors based on a hierarchical relationship with a parent type. Or maybe all the classes just need to be simple record / tuple wrappers and the methods that operate on them don’t belong to any class at all.

The reason examples like car extends vehicle cause harm is that they can be superficially taken as an endorsement that you should bring preconceived mental models of relationships between components into the solution, before trying to solve it with zero abstraction and observing where this breaks down.

Indentation breaks HN. Blockquote should not inherit from Codeblock.

Please remove it and use > for quotes.

> The `Car extends Vehicle` or `Duck extends Bird` type of tutorial obscures more than it illuminates. In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication (which comes to the same thing). Without any context as to what the code needs to accomplish, you can’t make a judgment about whether a design decision is good or bad.

Agreed, if the '1337 hax0rs at HN would implement quoting, then > would be a good way to express it.

As it stands, > does nothing on HN, so we're treated to endless complaints about people misusing code blocks for quoting. The complaints are valid, since code blocks don't work properly on mobile. Complain enough about either of these issues and they'll gripe at you for complaining. It never occurs to them that fixing the problems would avoid both the need for complaining and the need for griping. Oh, well, life goes on.

Reply on news.ycombinator.com