Hacker News Reader

Comment by Mikera | Hacker News Reader

The problem is the design paradigm where you enforce an arbitrary fixed hierarchy on real-world data.

This doesn't work for several reasons:

* In the real world there are multiple overlapping hierarchies, which have different uses. Human 'isa' SentientBeing as well, which may be a much better heirarchy for modelling communications with aliens and robots. Most OOP languages either don't handle this at all, or handle it badly.

* Your hierarchy will almost certainly have to change (you'll be wrong, or new requirements will come along). Frequent major code breakage / refactoring is the likely result. If you also need to persist data across versions, you're in big trouble.

Property / prototype based methods are in general much more flexible for real world data.

View on HN

> * In the real world there are multiple overlapping hierarchies, which have different uses. Human 'isa' SentientBeing as well, which may be a much better heirarchy for modelling communications with aliens and robots. Most OOP languages either don't handle this at all, or handle it badly.

There may well be overlapping hierarchies, and trying to capture taxonomy with an adequate analogy to explain the concepts of inheritance to somebody is perhaps not the best way. But to say that you must never enforce an arbitrary fixed hierarchy contradicts the very purpose of inheritance in a good design.

For your particular example the correct way is to have a separate interface called "ISentient" that captures whatever methods and fields are required for sentient communication.

Most OOP languages support that concept.

So you can have a Human that inherits from Mammal, but only Human introduces the ISentient interface. Your "Robot" can then inherit from "Machine" and also introduce ISentient.

A much better way is to use interfaces for most things: use IMammal then override "procreate" so you can account for specie extrema like the duck-billed platypus class, which is a mammal that lays eggs.

Could you elaborate on how prototype based OOP solves overlapping hierarchy and hierarchy modification? It is not clear to me, and it seems actually like multiple inheritance, mixins, interfaces, and/or type-classes would address multiple hierarchies reasonably well, while I am not sure how prototype inheritance does so at all.

Reply on news.ycombinator.com