# Is there a specific name for the "Square inherits from Rectangle" paradox?

A certain failure of OOP is shown with a class Square inheriting from Rectangle, where logically Square is a specialization of Rectangle and should therefore inherit from it, but everything falls apart when you attempt to change a Square's length or width.

Is there a specific term for describing what is going wrong with that case?

• could you please explain what exactly "is going wrong"? I don't understand what you mean
– gnat
Commented May 24, 2013 at 17:24
• Assuming a rectangle has a virtual method that allows one to set size by passing length and width, setting a different length and width on a square could return a rectangle and setting a same length and width on a rectangle could return a square. Any code that needs to know square explicitly can attempt to cast to a square. I don't see how there is a failure...
– user44798
Commented May 24, 2013 at 17:31
• This is not a paradox. This is a case of improper modeling of the problem domain. The inheritance hierarchy is NOT necessarily going to line up with the hierarchy of thing in the problem domain. It's nice when it does, but the trick in a good model is to understand where you need to do things differently than the real world. Commented May 24, 2013 at 18:38
• FWIW: More specifically, the problem is that the reading and writing interfaces don't match up. I.e. you can read a circle as a specialization of an ellipse, but only write an ellipse as a specialization of a circle. Commented May 24, 2013 at 19:07
• @GrandmasterB I go by "any person, thing, or situation exhibiting an apparently contradictory nature." The contradiction is that if the square has different properties, we have to say "a Square is not a sort of Rectangle", when it fact we expect Square to be a subtype of Rectangle. Probably no real application would have Rectangle and Square types, it's just an abstraction to illustrate a certain kind of problem that can appear in class-based paradigms. Commented May 25, 2013 at 16:11

Wikipedia merely refers to it as the Circle-ellipse problem

The circle-ellipse problem in software development (sometimes known as the square-rectangle problem) illustrates a number of pitfalls which can arise when using subtype polymorphism in object modelling. The issues are most commonly encountered when using object-oriented programming.

This is the L in the acronym S.O.L.I.D. which is known as the Liskov substitution principle. This problem arises as a violation of that principle.

The problem concerns which subtyping or inheritance relationship should exist between classes which represent circles and ellipses (or, similarly, squares and rectangles). More generally, the problem illustrates the difficulties which can occur when a base class contains methods which mutate an object in a manner which might invalidate a (stronger) invariant found in a derived class, causing the Liskov substitution principle to be violated...

• And, reading it, Wikipedia mentions the more academic explanation as "[violation of] the Liskov substitution principle". Thanks :) Commented May 24, 2013 at 17:35
• Well, it's only a violation depending on how you look at it. Personally, all circles are ellipses; there is no violation. There begins to be a violation if the methods for ellipse become to restrictive. Then, in that particular scenario, a circle cannot be a subtype of that particular contract of ellipse. Commented May 24, 2013 at 17:37
• @MarkCanlas The problem is unarguably a violation of the Liskov substitution principle. It may not be a violation of other principles, but nobody claimed that. When the problem does not occur because the contracts do not include any invariant that would be broken (though I fail to imagine a useful model where this is true), there may not be a violation of the LSP, but that doesn't mean the problem, when it occurs, isn't due to a LSP violation.
– user7043
Commented May 24, 2013 at 19:02
• @Mark Canlas: nope, constant circle is a constant ellipse, mutable circle is not a mutable ellipse. In geometry constantness is assumed, you cannot change an ellipse, you can take another ellipse Commented May 24, 2013 at 19:22
• The History Constraint/Rule of the Liskov Substitution Principle says that when a subtype adds new methods, those methods are not allowed to manipulate the state of the object in such a way that it creates a history (i.e. a series of states) that is not allowed in the supertype. E.g. you cannot make a subtype of an immutable mutable, because when only manipulated through methods of the supertype, the state is always the same, whereas when manipulated through the mutator methods of the subtype, the state does change. That's a history that is not allowed by the supertype. Commented May 26, 2013 at 0:27

I would consider it a violation of the Liskov Substitution Principle - the `Square` subclass specifically violates the invariant that length and width are independent.

At a more fundamental level than the Liskov Substitution Principle, this is a category error or category mistake

In the context of modeling behaviour a square simply is not a type of rectangle.

When you realize this the problem evaporates since the initial assumption (a square is a type of rectangle) is removed from play.

The issue with this answer is that since school it is drilled into anyone doing geometry that a square is a type of rectangle. But it is very important to understand that this is only true within a very specific context (the classification of geometric shapes based on the properties of their internal angles). In terms of behaviour a square is not a rectangle. To view one set of classification in the wrong context is a category mistake.