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. The polygon class should be sufficiently advanced to take arbitrary constraints and handle all properties generically. After all, a 71-sided polygon has no name, and we didn't write an object for that yet! Nor should we have to. 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.
It's like the canonical OO example of cats and dogs where the user writes canine and feline in there, and writes support in there for the future inclusion of fish. It just going to darn far.
Moral of the story -- Inheritance is a powerful weapon in the OO arsenal. It is but one of many weapons, and is the most overused hammer for the proverbial nail. Abuse of inheritance and not knowing when to inherit versus encapsulate objects has led to many coding problems I've seen in my work -- folks make this error in all sorts of languages, because the power of inheritance is very alluring. It takes a lot to hold it in check -- to know when it should not be used.
In reply to Re: Re: inheritance and object creation
by flyingmoose
in thread inheritance and object creation
by knew
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |