Re: inheritance and object creation

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

Comment on Re: inheritance and object creation

Replies are listed 'Best First'.
Shapes don't need inheritance by dragonchild (Archbishop) on Feb 25, 2004 at 18:07 UTC
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]
Re: Shapes don't need inheritance by Abigail-II (Bishop) on Feb 25, 2004 at 19:43 UTC
You too? I already explained to flyingmoose I was talking about shapes, not polygons. Why talk about polygons as well? Abigail	[reply]
Re: Re: Shapes don't need inheritance by dragonchild (Archbishop) on Feb 25, 2004 at 19:51 UTC
polygon: A closed plane figure formed by three or more line segments that do not cross over each other. (http://www.shodor.org/interactivate/dictionary/p.html) That is what most people refer to when they discuss shapes. Hence, why flyingmoose and I used the term polygon when replying to you. ------ 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]
Re: Shapes don't need inheritance by Abigail-II (Bishop) on Feb 25, 2004 at 20:01 UTC
Re: Re: inheritance and object creation by flyingmoose (Priest) on Feb 24, 2004 at 15:00 UTC
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]
Re: inheritance and object creation by Abigail-II (Bishop) on Feb 24, 2004 at 15:12 UTC
Well, just four classes with obvious relationships is pretty basic to me. And your solution is to not have any inheritance at all. Sure, not having any inheritance at all is a solution to "should we use multiple inheritance". I don't think that gives you any of one of the prime benefits of OO programming (code reuse) though. Abigail	[reply]