|
Re: inheritance and object creation
by Abigail-II (Bishop) on Feb 24, 2004 at 10:23 UTC
|
I think if you have to model the differences in polygons with an object model, you are really taking your object model too far down.
I didn't say polygons. I said shapes.
The polygon class should be sufficiently advanced to take arbitrary constraints and handle all properties generically.
Even if I were to be talking about polygons, I still don't
agree with that. If you follow such reasoning all the way
through, you would never subclass. Instead, you would make
you one and only base class more generic.
There shouldn't have to be classes for that, and to a mathematician, rules for a 71-sided polygon with equal angles are scarely different than a quad... the numbers just come out cleaner.
But as I said, I was thinking about shapes, and properties
of shapes. For instance, let's talk about simple symmetries.
All parallelograms have a rotational point
of symmetry (180 degrees around their center). This is not
true for all 71-sided polygons - in fact, 71 being odd, there is no 71-sided polygon that has a 180 degree rotational symmetry. Every rectangle has two lines of
symmetry - the lines dividing opposite sides, and whatever
symmetry a parallelogram has. Every rhombus has two lines
of symmetry, but different lines than the rectangle, namely
the diagonals. And in addition, it has the symmetries a
parallelogram has. Finally, a square has a 90 degree rotational symmetry, a -90 degree rotation symmetry, and the symmetries of
a rectangle, and the symmetries of a rhombus.
So, my question remains, what kind of inheritance tree
would you use? (And keep in mind, the tree is just part of
a bigger picture, there may be hundreds of other shapes as
well. If you want to collapse them into one general class,
you'll have to do a lot of case statements, and you're back
to non-OO programming).
Abigail
| [reply] |
|
|
You're mixing terms. A 71-sided polygon isn't a parallelogram, so to discard it because it doesn't have rotational symmetry is a straw man.
There are a set of properties that all polygons have (closed, etc), and a set of properties that all regular polygons have (regular angles, sides of the same length, and rotational symmetry at least 360/n degrees around the center, where n is the number of sides). This seems to lend itself to an inheritance tree, but, like the fibonacci sequence, the first approach isn't appropriate.
Instead, the more appropriate approach would seem to be to elaborate the rules that arise based on the properties of the object, not the class, and to (potentially) precalculate those results on object creation (with appropriate caching). For example, a square has certain properties. So, when an object of the ClosedShape class is instantiated that matches the properties of a square, the appropriate results would be calculated. But, it's still of the ClosedShape class.
I think that this would start to solve the generic and specific problems you have flyingmoose have raised.
------
We are the carpenters and bricklayers of the Information Age.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] |
|
|
You too? I already explained to flyingmoose I was talking
about shapes, not polygons. Why talk about polygons
as well?
Abigail
| [reply] |
|
|
|
|
|
|
No, you can still have classes and attributes, you just don't build a full inheritance tree. Again, inheritance is one of MANY tools, and only in the most basic of OO implementations is inheritance the key to the entire puzzle.
| [reply] |
|
|
| [reply] |
Re:x2 inheritance and object creation (naming polygons)
by grinder (Bishop) on Feb 24, 2004 at 13:48 UTC
|
After all, a 71-sided polygon has no name
Yes it has, it goes by the gentle name of monoheptacontagon, in case you were wondering :o)
| [reply] |
|
|
Ok, but what about a 73-sided polygon? I meant to say 73-sided polygon :)
| [reply] |
|
|
triheptacontagon. You're going to lose this one - there's a naming scheme for polygons, just like there is for molecules. (I actually work with someone who had to come up with the "official" name for various forms of carbon nanotubes. It's not easy, but it is relatively straightforward.)
------
We are the carpenters and bricklayers of the Information Age.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] |