January 27th, 2017
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
The Hierarchy Problem
Every time I start at a new company, I struggle with the problem when I’m creating a place to put my Company Documents, e.g. the Employee Handbook.
Do I create a folder called Documents and then create a folder called Company in that?
Or do I create a folder called Company and then create a folder called Documents in that?
Both work. But which is right? Which is best?
The idea of Categorical Hierarchies was that there were Base Classes (parents) that were more general and that Derived Classes (children) were more specialized versions of those classes. And even more specialized as we make our way down the inheritance chain. (See the Shape Hierarchy above)
But if a parent and child could arbitrarily switch places, then clearly something is wrong with this model.
The Hierarchy Solution
What’s wrong is…
Categorical Hierarchies don’t work.
So what are hierarchies good for?
If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere.
What you won’t find is Categorical Hierarchies. Let that sink in for a moment. The Object Oriented Paradigm was predicated upon the real world, one filled with Objects. But then it uses a broken model, viz. Categorical Hierarchies, where there is no real-world analogy.
But the real world is filled with Containment Hierarchies. A great example of a Containment Hierarchy is your socks. They are in a sock drawer which is contained in one drawer in your dresser which is contained in your bedroom which is contained in your house, etc.
Directories on your hard drive are another example of a Containment Hierarchy. They contains files.