Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
square/rectangle problem
- Thread starter djam
- Start date
DonQuichote
Programmer
- Nov 9, 2001
- 980
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
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.
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.
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.
DonQuichote
Programmer
- Nov 9, 2001
- 980
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 ( ) 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
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 ( ) 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
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.
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
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
andy715723
Programmer
"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
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.
"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.
>"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.
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.
- Status
Similar threads
- Locked
- Question
- Locked
- Question