Inheritance Often Doesn't Make Sense
&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.<p>Alternatively, you can argue that a rectangle is just a square with the additional freedom to vary the width and height independently. So in C++ syntax you would have:<p><pre><code>    class Square {
    protected:
      size_t width;
      &#x2F;&#x2F; No need to have &quot;height&quot; field because Square guarantees that height ==
      &#x2F;&#x2F; width.
    public:
      virtual size_t getWidth() const { return width; }
      virtual size_t getHeight() const { return width; }
    };
    
    class Rectangle : public Square {
      size_t height;
      &#x2F;&#x2F; A rectangle allows height to be different from width.
    public:
      virtual size_t getHeight() const override { return height; }
    };

</code></pre>
See? This makes OO hard because it&#x27;s hard to decide which should be the subtype of which intuitively, and people get even more confused since the arrow is contravariant in its left argument and the relationship would sometimes appear reversed. There in fact <i>is</i> one correct answer but people often get it wrong. You need some serious appreciation of OO to know which.<p>Here are some more examples that can cause confusion. Suppose we have Reference (which can be read or written), ReadableReference (read-only) and WritableReference (write-only). From a purity perspective, should we have Reference inherit from both ReadableReference and WritableReference (ignoring OO languages that don&#x27;t allow multiple inheritance), or should we have ReadableReference and WritableReference inherit from a single base class Reference? This kind of question frequently trips people up.