Inheritance Often Doesn't Make Sense
This gets off to a bad start:<p>&gt; There are three different types of inheritance going on.<p>&gt; 1. <i>Ontological</i> inheritance is about specialisation: this thing is a specific variety of that thing (a [soccer ball] <i>is</i> a sphere and it has this radius)<p>&gt; 2. <i>Abstract data type</i> inheritance is about substitution: this thing behaves in all the ways that thing does and has this behaviour (this is the Liskov substitution principle)<p>&gt; A common counterexample to OO inheritance is the relationship between a square and a rectangle. Geometrically, a square is a specialisation of a rectangle: every square is a rectangle, not every rectangle is a square. For all s in Squares, s is a Rectangle and width of s is equal to height of s. As a type, this relationship is reversed: you can use a rectangle everywhere you can use a square (by having a rectangle with the same width and height), but you cannot use a square everywhere you can use a rectangle (for example, you can’t give it a different width and height).<p>&gt; Notice that this is incompatibility between the inheritance directions of the <i>geometric properties</i> and the <i>abstract data type properties</i> of squares and rectangles; two dimensions which are completely unrelated to each other<p>By the definitions given at the beginning, where the &quot;abstract data type properties&quot; of an object are its properties as considered by the Liskov substitution principle, this is nonsense.<p>Compare the definition stated in <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Liskov_substitution_principle" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Liskov_substitution_principle</a> . Type S is substitutable for type T when, if f(<i>x</i>) is true of all objects <i>x</i> of type T, then f(<i>y</i>) is true of all objects <i>y</i> of type S.<p>Obviously, according to this definition, any subtype S of type T which satisfies the article&#x27;s definition 1 will also be Liskov substitutable for T and therefore satisfy the article&#x27;s definition 2 as well. This is as far from being &quot;unrelated concepts&quot; as you can get; the one requires the other.<p>The example with Squares and Rectangles doesn&#x27;t make sense either. If you have code that is set up to handle Rectangles, and you give that code a Square, then the code will handle the Square correctly. This is <i>because</i> Squares are Liskov substitutable for Rectangles... which is <i>because</i> Squares are, platonically, a kind of Rectangle.<p>It looks like the author wants to ask &quot;if I encounter an interface that processes Rectangles, and I can only construct Squares, can I achieve everything, by using Squares, that someone else could have achieved by using Rectangles?&quot; But that is not the Liskov substitution principle, or any sort of type theory principle. That would be a principle of computational equivalence.