I think you've hit on something very important, essential, in the problem with OO-as-taught. This is something that is known in many quarters of skillful pract

I think you've hit on something very important, essential, in the problem with OO-as-taught. This is something that is known in many quarters of skillful practictioners, but missed by most schools or beginners. I think the first part of this article is misleading, in that it waxes philosophical about the drawbacks of defining things in an ontology. But then it then proceeds to figure out a better way to model things as an ontology! The issue isn't with ontologies -- yes, slapping a hierarchy or meronymy on something isn't perfect, but it's pretty useful when organizing concepts. The fundamental problem with OO inheritance, is that it is not ontological or mathematical inheritance! OO inheritance has almost no relationship to thousands of years of what "is-a" means -- i.e. subset. It's backwards - subclasses are extensions, or supersets of their parents. The way to implement inheritance correctly is "specialization by constraint", i.e. you define a subclass by the constraints it has on its superclass. This is what's happening in the latter part of the article, with design-by-contract and test cases for your various classes. This is also, by the way, how ontology languages like OWL work, and in part why they're so hard to learn/use -- their notion of inheritance and "subclassing" is the mathematical notion (i.e. more like subset), and the opposite of OO programming languages, so we have 25+ years of history to unlearn. I suspect the reason OO inheritance took the path it did was for simple expediency on the part of compiler writers & language designers. Specialization by constraint ain't easy to implement declaratively.