Hacker News Reader

Comment by lbarrow | Hacker News Reader

I concede the example is a bit of a straw man. But I'd challenge you to provide a similarly concise problem and solution where 1) inheritance is useful and 2) there isn't a better solution that doesn't use inheritance.

View on HN

1. Inheritance is about extensibility. You won't encounter suitable applications in self-contained toy universes where you can almost always rewrite something as some form or another of a typecase statement (whether that's Pascal-like variant records with case statements or ML/Haskell-style pattern matching). See also the expression problem [1].

2. "Inheritance" itself is a fairly fuzzy concept. Do you mean implementation inheritance (for code reuse), polymorphic subtyping (for polymorphism with late binding), do you account for virtual types, etc.?

[1] http://c2.com/cgi/wiki?ExpressionProblem

The classic examples...

Person > Employee > Manager

Shape > Rectangle, Circle

Object > anything

Product > Book, TV

I think these are good examples where inheritance makes lot of sense. There is commonality between things and there is specialization (overrides) or definitions (abstract methods). It's wrong to say that the concept of inheritance is evil. Like pretty much everything, it can be severely abused (very deep hierarchies, multiple on inheritence etc). The classic example of OOP abuse is probably things like MFC library.

I would disagree with regards to the Person chain. Mainly because being an employee is a role, as opposed to being a kind of people.

It's hard to evaluate whether or not those examples make sense without some pseudocode showing how the classes are used.

Would you also support Shape > Rectangle > Square? Or are all your super classes abstract?

If we're being cheeky, a square is also a rectangle. Unless I'm misreading your post, I'd expect your superclasses to be as abstract as they needs to be and no more:

  Vehicle < Car, Truck, etc.
  Person < Employee, Customer, etc.

There's a pretty obvious logic to them that doesn't really demand much extra thought. I can't think of anyone outside of an irreverent ontologist who would suggest going beyond that unless there's a valid reason for it, like say:

  PhilosophicalBeing < Person < Employee, Customer, etc.

A mutable square is not a mutable rectangle, because a mutablr rectangle can change its width independently of its length. This is the classic problem of contravariance: subtyping in the face of mutability.

Good point. Without giving it much if any thought, I made an assumption--that the square is immutable--that probably wouldn't even be accurate in this context. In fact, it's the usual example used to talk about substitutability. Oops.

"better solution" is subjective though.

Reply on news.ycombinator.com