This question already has an answer here:
So, we're all probably familiar with the example provided in most textbooks of the Liskov substitution problem involving a square inheriting from rectangle. The objection to this approach is that while a square “is a” rectangle in a mathematical sense, the parent class, rectangle, cannot easily described in terms of a square and thus this model violates one of the fundamental parts of SOLID programming—the Liskov substitution principle.
My question is does it make sense for us to invert the dependency from square "is a" rectangle to rectangle "is a" square. Obviously, in a mathematical setting this is wrong. But a large percentage of why we use OOP is to reduce the amount of, semi unique, code which has to be written, or copy pasted, from place to place. It seems like a relationship between these two structures makes sense, but clearly not the parent child relationship we see in the classical statement of the problem.
I just finished a course on software engineering and I don't think that this point was clearly explained. I know that just because there is an “is a” relationship between two classes does not necessarily imply that there should be any abstraction at all, but it seems satisfying in a mathematical sense for there to be a connection between the two classes.
Also note that I am working on, as a side project, a small game engine and some kind of abstraction between them might make sense.