Should rectangle inherit from square? [duplicate]

Question

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.

Answer 1

The classic example of square not being able to substitute for rectangle without violating LSP is a bit of a "trick question" and sophistic.

The problem arises because of a conflation... i.e. an implementation of a rectangle is not really a rectangle.

Having independently settable width and height is not an inherent property of a rectangle. A rectangle is still a rectangle even if its width and height are immutable.

Therefore for any given rectangle, it is reasonable that one must not assume anything about constraints (or lack of constraints) on its dimensions. A mathematical rectangle is just that, nothing less, nothing more, and a mathematical square IS in fact a specific perfect example of a mathematical rectangle.

However a rectangle that is guaranteed to have an independently adjustable width and height (as one would normally code behavior in order to make the class useful) is not in fact a rectangle... it is something else. It's a rectangle PLUS certain additional guaranteed behavior.

Therefore this example arises because it creates new things, which are neither rectangles nor squares, but mis-labels them "rectangles" and "squares" and then exclaims "whoa! here's a weird case of some perfect subset violating LSP!". Well that's not the case at all. New things have been created that are neither rectangles nor squares.

To directly answer the OP's question, no it doesn't make sense either mathematically or in computer science to regard a rectangle as a kind of square. I can't see any good reason why one would inherit rectangle from square. Creating methods in that architecture would quickly bear little resemblance/natural mapping to what those words mean to us normally.

Answer 2

Liskov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.

Therefore:

• Square cannot inherit from Rectangle.

  Imagine the following function, shamelessly copied from Robert C. Martin's Agile Software Development, page 115, The Real Problem:

  void g(Rectangle& r)
  {
      r.SetWidth(5);
      r.SetHeight(4);
      assert(r.Area() == 20);
  }
  

  One may find it useful to quote the book a few paragraphs below:

  One might contend that the problem lays in function g—that the author had no right to make the assumption that width and height were independent. The author of g would disagree. The function g takes a Rectangle as its argument. There are invariants, statements of truth, that obviously apply to a class named Rectangle, and one of those invariants is that height and width are independent. The author of g had every right to assert this invariant. It is the author of Square who has violated the invariant.

  Indeed, what happens is that we could imagine a bunch of contracts associated with the rectangle class. Those contracts can be written in code, such as in C# or Java, or be part of the public interface, such as in Eiffel or Spec#, or be only assumed or written in a form of comments.

  One of the contracts is suggested by Robert C. Martin and consists of the postcondition of Rectangle::SetWidth(double w):

  assert((itsWidth == w) && (itsHeight == old.itsHeight));
  

  Square violates this postcondition, since itsHeight == old.itsHeight would return false.

• Rectangle cannot inherit from Square.

  Here, the same logic applies. Imagine that Rectangle inherits now from Square. The function g(Square& s) changes the width of the square, for instance by multiplying it by two. Given the definition of the square, it is wise to assume that the surface area will be multiplied by four.

  However, passing an instance of the Rectangle class to g will violate the assumption, since the new surface area will only double instead of quadruple. Same logic applies here, and means that inheriting Rectangle from Square is equally bad.

Answer 3

Object oriented design models behavior, rather than any mathematical properties.

So the short answer is that since a square cannot act like a rectangle and a rectangle doesn't act like a square, they have no child-parent relationship, either way.

The longer answer is a square is a special form of a rectangle only in a specific domain, that being geometric properties. OOD deals with a different domain, modelling behaviour of interacting objects. As such if the relationships are not relevant to this domain you should ignore them. Attempting to model relationships that are actually irrelevant to how the system will behave causes big problems in a system. Stick to the relationships that matter to the behaviour of the system.

Answer 4

Inheritence does not apply at all, either way. Although every square is a rectangle, it does not add anything to the rectangle. It just is a rectangle period, it does not extend rectangle. Inheritence is pointless unless the descendant is (expected) to extend the base class somehow.

The confusion stems from the human label "square" which is totally arbitrary. If people would call a rectangle with long sides twice the length of the short sides a doubie, and the word would be in the English dictionary, you would see the same question about doubies and rectangles on stackexchange.

The same goes for circles and ellipses. Ellipse is the type, circle is just a common incarnation of it.

Answer 5

Rectangle must not inherit from Square. A square is a special form of a rectangle (where all sides have equal length). So the general form is Rectangle and Square is a specialization. So you can draw a generalization from Square to Rectangle, but not vice versa.

Regarding the Liskov-substitution: if you introduce constraints, you get around the pitfalls. Definitely it's tempting to "just inherit" but of course you still have your brain. And that revealed the problem behind the circle/ellipsis inheritance. So you need to be aware of what you are doing and care for the non-obvious. And: dogmatic programming is not necessarily good programming.

Let's look at a simple design:

Since height/width are protected you need setter methods to alter them. And the constraint on Square will ensure that both height and width must be equal. Now, there can be different implementations for Square. Either a setHeight will as side effect alter the width (which does not seem to be a good idea). Or you raise an exception when trying to do so, which can be implemented in the overrides. As a convenience you can add a setSize with just a single int for height/width which is only available in Square. You can extend this design in similar way with various methods.

Answer 6

As you pointed out, it is neither a good idea for Square to inherit from a modifiable Rectangle (any new code in Rectangle could create Squares that are not, well, squares), nor is it a good idea for Rectangle to inherit from Square (the general Rectangle is not a square, so it is a clear violation of the substitutability rule).

The problem must be tackled in another way. Options are:

• Make both Square and Rectangle immutable. If the constructor is the only point where the lengths can be set, there is no danger of a Square suddenly becoming a non-square through the use of methods in Rectangle. Also, this helps at implementing strict value semantics, which make code much more readable.

• Forget about Square and simply use a Rectangle which just happens to have the same width and height. May be combined with immutability as above, and you might want to add a constructor that takes only a single size argument to construct a Rectangle that happens to be a square.

• If you need affine transformations anyway, you can also go the exact opposite route: Have only a square that occupies the rectangle between (0,0) and (1,1), and add an affine transformation to every such square to translate it, stretch it, rotate it, shear it to the precise parallelogram shape you want. Of course, you will have a constructor for axis aligned squares, and one for axis aligned rectangles, but from that point on, you have near absolute freedom. Of course, this is a rather heavy-weight solution, but quite a good one in certain contexts.

Which solution works best for you depends entirely on your use-case. But I've found that it's usually not a bright idea to force something into an inheritance relationship that does not want to be in it. Square and Rectangle are such a pair. Instead, look for solutions that avoid the problem in the first place. That is, what makes a good software developer: The ability to think out of the box, and to come up with creative, simple solutions that fit the current problem at hand easily.

Answer 7

I think it can work both ways. You can apply the Strategy Pattern. Although there are not much real life distinct rectangle objects with varying sides.

According to the Strategy Pattern, your square can extend a rectangle - so as it can be correct mathematically. Also, since rectangles and squares all have 4 sides, this should be common for the parent rectangle class. Since the length of the sides are different, you can create an interface <> and have various side lengths implement it. Whereas the Parent rectangle class will be composed of SideLengths instance variables.

I think you can just avoid these complexities and just create separate square and rectangle classes.