4 ms·
Actually it buys polymorphism. And the square/rectangle example is rather contrived, not to mention wrong, as it assumes a naive constructor, er, construction:
by foljs 16y ago
Actually it buys polymorphism.
And the square/rectangle example is rather contrived, not to mention wrong, as it assumes a naive constructor, er, construction:
a) of course a square is a rectangle.
b) who said that you cannot add constraints to your model?
Oh, and by the way: the rectangle/square relationship is not "world modeling" --it's mathematics, as close to pure logic as it gets.
- haberman 16y ago> Actually it buys polymorphism. So does "square and rectangle both derive from polygon," but without the problems. (For "polygon" substitute "shape" or "drawable_thing" or whatever based on what your program is doing). And "polymorphism" by itself isn't an end unless it makes your program better. > of course a square is a rectangle. Let me ask you this: is it your opinion that because a square is mathematically a rectangle that you should automatically express this with an inheritance relationship, even if it makes the program worse? If so you are exactly the person that my message needs to reach. Please take it to heart and think about the hurt you are inflicting on the people you work with. > Oh, and by the way: the rectangle/square relationship is not "world modeling" --it's mathematics, as close to pure logic as it gets. It's absolutely "world modeling." You're trying to take some ontological fact about some object (in this case, a mathematical object) and express that in a software design.
- foljs 16y ago> So does "square and rectangle both derive from polygon," but without the problems. Well, there are SEVERAL kinds of modeling you can do, depending on your application needs. I mean, no shit Sherlock! Still, the problem with polygon -> rectangle still exist, you still need to have contraints. > And "polymorphism" by itself isn't an end unless it makes your program better. The same holds true for EVERY language feature: it's only useful if it makes your program better --so it's a tautology irrelevant here. > Let me ask you this: is it your opinion that because a square is mathematically a rectangle that you should automatically express this with an inheritance relationship, even if it makes the program worse? No, it's my opinion that if you express mathematical truths right, programs generally get BETTER. The right way is not always inheritance ―it's not even a basic feature of OO programming according to Alan Kay―, but in this case the example fits, and the "problem" spot you mention is contrived and easily solved. And if you don't like theory, here's practice and history for you: a) almost EVERY successful game and drawing program written in a OO language, or C with some hacks (that makes 99% of 'em), uses such a shape hierarchy. > It's absolutely "world modeling." You're trying to take some ontological fact about some object (in this case, a mathematical object) and express that in a software design. Math (and logic) != world. And a "mathematic object" is not an object, it's the expression of some axioms and constraints. The more faithfully you capture those in your code, the better off you are.