

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise

I am new to design and learning the design principles.

It says deriving square from rectangle is a classic example of violation of Liskov's Substitution Principle.

If that's the case, what should be the correct design?

share|improve this question
up vote 35 down vote accepted

I believe the reasoning is something like this:

Let's say you have a method that accepts a rectangle and adjusts its width:

public void SetWidth(Rectangle rect, int width)
    rect.Width = width;

It should be perfectly reasonable, given what a rectangle is, to assume that this test would pass:

Rectangle rect = new Rectangle(50, 20); // width, height

SetWidth(rect, 100);

Assert.AreEqual(20, rect.Height);

... because changing a rectangle's width does not affect its height.

However, let's say you've derived a new Square class from Rectangle. By definition, a square has height and width always equal. Let's try that test again:

Rectangle rect = new Square(20); // both width and height

SetWidth(rect, 100);

Assert.AreEqual(20, rect.Height);

That test will fail, because setting a square's width to 100 will also change its height.

Thus, Liskov's substitution principle is violated by deriving Square from Rectangle.

The "is-a" rule makes sense in the "real world" (a square is definitely a kind of rectangle), but not always in the world of software design.


To answer your question, the correct design should probably be that both Rectangle and Square derive from a common "Polygon" or "Shape" class, which does not enforce any rules regarding width or height.

share|improve this answer
Second example, should the assert be testing for 50? BTW, in the "real world" a square is either not mutable (is drawing on a page) or it can cease to be a square when a force is applied (its made out of rubber), IOW in the real world an object can change type dynamically something we don't model very well in programming languages. – AnthonyWJones Jun 23 '09 at 10:58
Oops well spotted on the second example. The test is right - the ctor parameter is wrong. Clipboard inheritence bug! I will fix it now. – Matt Hamilton Jun 23 '09 at 11:33

The answer depends on mutability. If your rectangle and square classes are immutable, then Square is really a subtype of Rectangle and it's perfectly OK to derive first from second. Otherwise, Rectangle and Square could both expose an IRectangle with no mutators, but deriving one from the other is wrong since neither type is properly a subtype of the other.

share|improve this answer
+1, YEP! I've been saying this for 20+ years and hardly anybody's been listening... – Alex Martelli Jun 23 '09 at 4:08
Good point there with mutability. – Gishu Jun 23 '09 at 4:30
Perceptive. I suppose you could generalise slightly further by saying that the truth of the statement "A is a subtype of B" depends on the public interface exposed by B. A smaller interface (e.g. an interface lacking mutators) reduces the amount you can "do" with concrete objects of that type or its subtypes, but gives you more opportunities for subtyping. – j_random_hacker Aug 17 '09 at 6:54
@Anton I would say IShape makes more sense than the IRectangle in this context. What do you think? – Geek Sep 27 '13 at 4:26
I don't think so. IShape would make sense in a context which considered all shapes, including non-rectangular ones, but this context we're discussing here doesn't. We're talking about just squares and rectangles here; triangles and circles need not apply. – Anton Tykhyy Sep 27 '13 at 8:14

Let's assume we have the class Rectangle with the two (for simplicity public) properties width,height. We can change those two properties: r.width=1, r.height=2.
Now we say a Square is_a Rectangle. But though the claim is "a square will behave like a rectangle" we can't set .width=1 and .height=2 on a square object (your class probably adjusts the width if you set the height and vice versa). So there's at least one case where an object of type Square doesn't behave like a Rectangle and therefore you cannot substitute them (completely).

share|improve this answer

I don't agree that deriving square from rectangle necessarily violates LSP.

In Matt's example, if you have code that relies on width and height being independent, then it does in fact violate LSP.

If however, you can substitute a rectangle for a square everywhere in your code without breaking any assumptions then you're not violating LSP.

So it really comes down to what the abstraction rectangle means in your solution.

share|improve this answer
This is correct, but it's kind of pointless to have a Square class unless you use its invariants in the program :) – Anton Tykhyy Jun 23 '09 at 4:33
I could imagine having a code base that works on image rectangles. Then you get an idea for a performance optimization if the rectangles happen to be square. So yes, you are using the width/height invariant internally in the square, but it is invisible to the outside world (Only if no assumptions are made in the code on the orthogonality of width and height, of course). – Hans Malherbe Jun 23 '09 at 5:35
I agree, but this doesn't cover the case of someone else using Rectangle invariants, like ones suggested by Matt above. I didn't notice this when I wrote the first comment. – Anton Tykhyy Jun 23 '09 at 6:41

I believe that OOD/OOP techniques exist to enable software to represent the real world. In the real world a square is a rectangle that has equal sides. The square is a square only because it has equal sides, not because it decided to be a square. Therefore, the OO program needs to deal with it. Of course, if the routine instantiating the object wants it to be square, it could specify the length property and the width property as equal to the same amount. If the program using the object needs to know later if it is square, it needs only to ask it. The object could have a read-only Boolean property called “Square”. When the calling routine invokes it, the object can return (Length = Width). Now this can be the case even if the rectangle object is immutable. In addition, if the rectangle is indeed immutable, the value of the Square property can be set in the constructor and be done with it. Why then is this an issue? The LSP requires sub-objects to be immutable to apply and square being a sub-object of a rectangle is often used as an example of its violation. But that doesn’t seem to be good design because when the using routine invokes the object as “objSquare”, must know its inner detail. Wouldn’t it be better if it didn’t care whether the rectangle was square or not? And that would be because the rectangle’s methods would be correct regardless. Is there a better example of when the LSP is violated?

One more question: how is an object made immutable? Is there an “Immutable” property that can be set at instantiation?

I found the answer and it is what I expected. Since I'm a VB .NET developer, that is what I'm interested in. But the concepts are the same across languages. In VB .NET you create immutable classes by making the properties read-only and you use the New constructor to allow the instantiating routine to specify property values when the object is created. You can also use constants for some of the properties and they will always be the same. From creation forward the object is immutable.

share|improve this answer

I've been struggling with this problem a lot lately and thought I'd add my hat into the ring:

public class Rectangle {

    protected int height;    
    protected int width;

    public Rectangle (int height, int width) {
        this.height = height;
        this.width = width;

    public int computeArea () { return this.height * this.width; }
    public int getHeight () { return this.height; }
    public int getWidth () { return this.width; }


public class Square extends Rectangle {

    public Square (int sideLength) {
        super(sideLength, sideLength);


public class ResizableRectangle extends Rectangle {

    public ResizableRectangle (int height, int width) {
        super(height, width);

    public void setHeight (int height) { this.height = height; }
    public void setWidth (int width) { this.width = width; }


Notice the last class, ResizableRectangle. By moving the "resizableness" into a subclass, we get code re-use while actually improving our model. Think of it like this: a square cannot be freely resized while remaining a square, whereas non-square rectangles can. Not all rectangles can be resized though, since a square is a rectangle (and it cannot be freely resized while retaining its "identity"). (o_O) So it makes sense to make a base Rectangle class which is not resizable, since this is an extra property of some rectangles.

share|improve this answer

The problem is that what is being described is really not a "type" but an cumulative emergent property.

All you really have is a quadrilateral and that both "squareness" and "rectangleness" are just emergent artifacts derived from properties of the angles and sides.

The entire concept of "Square" (or even rectangle) is just an abstract representation of a collection of properties of the object in relation to each other and the object in question, not the type of object in and of it's self.

This is where thinking of the problem in the context of a typeless language can help, because it's not the type that determines if it's "a square" but the actual properties of the object that determines if it's "a square".

I guess if you want to take the abstraction even further you wouldn't even say you have a quadrilateral but that you have a polygon or even just a shape.

share|improve this answer

Its pretty simple :) The more 'base' the class (the first in the derivation chain) should be the most general.

For example shape -> Rectangle -> Square.

Here a square is a special case of a rectangle (with constrained dimensions) and a Rectangle is a special case of a shape.

Said another way - use the "is a" test. A squire is a rectangle. But a rectange is not always a square.

share|improve this answer
You have missed the point in the question with respect to the "Liskov substitution principle". See which explains how the 'is a' test is not adequate with respect to this principle for the very case of rectangle->square. The answer is not so 'simple'. (I did not mark you down). – Roger Nelson Jul 8 '09 at 23:37

Your Answer


