is a square a rectangle?
is a rectangle a square?
or is a square and a rectangle a shape?

whats the best way to model this in OO

"so many events, so little time"

A square is a rectangle but a rectangle is not square and further more both are shapes including circles and triangles.

Good Luck

The best way to model it depends on your needs.

A rectangle can "accidentally" be a square. If that doesn't have any consequences in your program, then why bother writing a separate class for squares?
Regarding them as separate entities is worth the effort if they need to behave differently.

Best regards

However...eh hm...taxonomically, a rectangle and a square could be a shape, but depending on how you work with your classes, rectangle being a square or vice versa wouldnt work.  If you decide a square is a type of rectangle you run into problems.  If you decide a rectangle is a square, you run into even more problems.  These problems relate to the Substitution Principle, and you end up not being able to substitute either - which thus violates the fundamental precepts to using "implementation/extension inheritance".

HTH

Nick.

This is the crux of OO - namely, reaching an appropriate level of abstraction. It really does depend what you want you app to do both now and in the future.

On the face of it, I'd be inclined to say that a Square was an instance (object) of the Rectangle class whose properties (height and width) just happened to be the same, not a class in its own right.

It really does depend what you want you app to do both now and in the future.

In the Extreme Programming methodology, There's a word for it: YAGNI (You Ain't Gonna Need It). It depends on what you want your application to do now. The beauty of most OO languages and IDEs is that the "future" can always be added later. Don't try to deal with things you don't need.

See the refactoring book and site (http://www.refactoring.com ) for how to change existing code reliably.

In fact, if your language has inheritance, you can add a Square class later that inherits from Rectangle. This way, you don't have to change anything in existing code.

Best regards

What I meant was be careful not to get yourself into a corner. I agree that you don't want to add functionality you don't need, but you do (imho) want to make sure that the framework is extensible.

To expand on what I mean...
If your app only needs to deal with squares, and will only ever need to deal with squares, then a Squares class is all you need - Shapes and Rectangles don't come into it.

If your app only needs to deal with squares now, but in the future will need Rectangles and other shapes, then its a good idea to incorporate these abstractions into your class hierarchy from the outset.

You can only use inheritance if you have something appropriate (ie more generic) to inherit from - ie. you can't inherit from Squares to get Shapes, for example.

OK, you can refactor the code at a later point, but its a lot easier, quicker and cheaper to just drop in an extra class into a well thought out inheritance hierarchy than to refactor the design to accomodate requirements that were anticipated from the outset.

The point is, that all abstraction is an approximation - you need to make sure its appropriate to what you want, and there is, therefore no definitive answer to the original question.

"However...eh hm...taxonomically, a rectangle and a square could be a shape, but depending on how you work with your classes, rectangle being a square or vice versa wouldnt work.  If you decide a square is a type of rectangle you run into problems.  If you decide a rectangle is a square, you run into even more problems.  These problems relate to the Substitution Principle, and you end up not being able to substitute either - which thus violates the fundamental precepts to using "implementation/extension inheritance"."

is nonsense.  Given a base class of Shape, you could:-

Inherit Shape to Quadrilateral
Inherit Quadrilateral to Trapezium
Inherit Trapezium to Rectangle
Inherit Rectangle to Square

Each subsequent class takes on the properties of it's predecessor and overrides and extends as necessary.  None of this prevents Square from being cast as a Shape.  However, Shape cannot necessarily be cast as a Square.

Craig

"A quadrilateral is a four-sided polygon with four angles. There are many kinds of quadrilaterals. The five most common types are the parallelogram, the rectangle, the square, the trapezoid, and the rhombus. "

math.com

squares and rectangels are siblings

Uhh, I may be wrong, but I don't think the quote from math.com implies that squares and rectangles are siblings.  I think it means only that they are both descendents of quadrilaterals.  My knowledge of the terminology might not be right, but I'm pretty sure that they are not siblings.  Also -

"Every square is a rectangle" is true.
"Every rectangle is a square" is NOT true.
which means that a square class can logically be derived from a rectangle class.

"Every rectangle is a shape" is true.
"Every shape is a rectangle" is NOT true.
so it makes sense to derive rectangle from shape.

As several people have said already, whether you actually derive a separate square class from a rectangle class depends on whether you require different implementations for squares than you do for generic rectangles.

>"Every square is a rectangle" is true.
>"Every rectangle is a square" is NOT true.
>which means that a square class can logically be derived
>from a rectangle class

So what behaviors/methods and properties do squares have that rectangles don't?

The only significant difference between a rectangle and a square (that I know of) is that the length and width of a rectangle may or may not be equal, whereas the length and width of a square are always equal.

As far as behaviors/methods are concerned, rectangles and squares know how to compute their perimeter and area. The formulas (formulae?) for computing the perimeter and area of a rectangle still hold true for a square.

I'm not sure it's really necessary to model 'square' as a subclass of 'rectangle'. Seems to me that a square is just a rectangle with its properties 'length' and 'width' having the same value, like PatHill said.

I agree with everything varocho said.

However, if you do have some fancy optimization that only works if the length and width are equal, it is good to know that square can be logically subclassed from rectangle (which many people have already explained long ago in this thread).  I disagree with andy715723's assertion that square and rectangle are siblings.  For example, subclassing square directly from shape and separately subclassing rectangle directly from shape would be bad because nearly all of the code would be duplicated, and because logically it is incorrect.