When approaching object orientation, I usually take a low level approach.<p>A class is a data structure.<p>An object is the actual data.<p>A method is a function talking an object as the first parameter<p>A subclass is a data structure containing first the parent class data structure, then the elements specific to the subclass. It means that inheritance is a special case of composition.<p>Virtual methods are function pointers in an object (often with a level of indirection: the vtable).<p>So instead of thinking of inheritance as a "is a" relationship, I treat is as "has (the properties of) a", because that's how it is in memory. For example, we often do stuff like an employee is a person, so employee inherits from person, and adds some extra properties, like pay. But I prefer to think of it as "an employee has the properties of a person". But we also decide that the "person" properties are special, because these are the properties you will use often, so you use inheritance instead of composition, and doing that, you take advantage of some syntactic sugar and an efficient memory representation.<p>So for that number tower, do you want "integer" to inherit "natural". Probably not, because while an integer has the properties of a natural with an additional "sign" property, you are unlikely to want to address your integer as a natural, there are few cases where it makes sense, so explicit composition would be more appropriate. In the reverse direction, do you want "natural" to inherit "integer". Maybe, it depends on how "special" natural numbers are over integers.<p>OOP may be flawed from a mathematical perspective, but it is a good tool for practical programming, that's why it is so popular. The "is a" and "has a" relationships are just to help understand a concept that is really about chunks of memory.