Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
could you please explain what exactly "is going wrong"? I don't understand what you mean –  gnat May 24 '13 at 17:24
    
Maybe it makes more sense for Rectangle to inherit from Square. –  CWallach May 24 '13 at 17:26
1  
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... –  tuespetre May 24 '13 at 17:31
    
@gnat, if a method had a rectangle, it might assume mutating the width would have no effect on the length. Maybe it doubles with width and expects the area to similarly double. When given a square, that assumption is out the window, provided that the square is correctly implemented. Double the width, the area quadruples. It also begs the question of whether the square needs separate width and length accessors/mutators. –  Anthony Pegram May 24 '13 at 18:33
4  
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. –  Michael Kohne May 24 '13 at 18:38

3 Answers 3

up vote 21 down vote accepted

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...

share|improve this answer
1  
And, reading it, Wikipedia mentions the more academic explanation as "[violation of] the Liskov substitution principle". Thanks :) –  Victor May 24 '13 at 17:35
1  
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. –  Mark Canlas May 24 '13 at 17:37
6  
@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. –  delnan May 24 '13 at 19:02
3  
@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 –  maxim1000 May 24 '13 at 19:22
    
@maxim1000: Exactly. After all, the important contribution of the LSP over other definitions of subtyping is the History Rule, which allows it to work with mutable objects and not just immutable values like older definitions did. –  Jörg W Mittag May 24 '13 at 22:38

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.