Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Robert C. Martin on 11 Jun 2005 22:03 On Sat, 11 Jun 2005 12:15:02 +0100, Gerry Quinn <gerryq(a)DELETETHISindigo.ie> wrote: >Another good example of a bad example is Chess, where Knight, Bishop >etc. inherit from Piece. I completely agree. The objects in a chess game are more likely to be boards and moves. A board represents a particular state that can be evaluated. A move changes the state of the board. We want to push moves on a stack and use 'do' and 'undo' methods as we hunt for boards with good evaluations. ----- Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 "The aim of science is not to open the door to infinite wisdom, but to set a limit to infinite error." -- Bertolt Brecht, Life of Galileo
From: Jeff Brooks on 11 Jun 2005 14:35 CTips wrote: > Jeff Brooks wrote: > .... snip ... >> Model shapes as a series of lines/curves then test for intersections >> on the lines/curves that make up the shapes. >> >> This was really easy to solve?! Why do you think it's a problem? >> >> Jeff Brooks > > Leaving aside the fact that you've ignored the problem of one shape > being "inside another", you've just moved the problem. It works fine when shapes are inside another shape. class CompositeShape extends Shape { private List shapes = new ArrayList(); boolean intersect(Shape aShape) { Iterator iterator = shapes.iterator(); while (iterator.hasNext()) { Shape shape = (Shape)shapes.next(); if (shape.intersect(aShape) { return true; } } return false; } } > The problem is now: how would you add the method: > class curve { > // true if this curve intersects with <B> > boolean intersects(curve B); > } > to the class hierarchy of curves? No that's not the problem now. In my design I don't have a class hierarchy of curves (curves, and lines are not shapes). A series of simple curves can make up any complex curve so I never need to extend curve. Jeff Brooks
From: Laurent Bossavit on 11 Jun 2005 14:43 > Okay, how about wiki's. How does specificly does polymorphism improve > wiki's beyond what a procedural version can do? Polymorphism is an abstraction enabler. The idea is that if we are to describe processes at a relatively high level of abstraction, we are necessarily going to describe in "umbrella" terms a class of situations. For instance, we might say "One feature of the Wiki is that it logs all edits." Now, "edit" is a nicely abstract term. At a lower level of abstraction, we may well have different kinds of edits: major, minor, spellcheck, file upload, page deletion... It's a win that we're able to implement the logging feature by writing, in a *single* place (wherever that is), for (Edit each in edits) logStream.append("Edit at "+edit.date()+": "+each.debugString()) Laurent
From: CTips on 11 Jun 2005 18:43 Willem wrote: > Jeff wrote: > ) CTips wrote: > )> Jeff Brooks wrote: > )>> In my design I don't have a class hierarchy of curves (curves, and > )>> lines are not shapes). A series of simple curves can make up any > )>> complex curve so I never need to extend curve. > )> > )> Not true. > ) > ) It is true. > ) > ) ... > ) > ) I'm not going to consider a curve based on your definition because your > ) definition is flawed in this context. I suggest you look up "bezier curve". > > So you don't see any need to be able to draw a circle ? > > > SaSW, Willem zing! :) But its a bit of a waste of effort. Once he made the preposterous claim that any curve can be approximated with a combination of simpler curves, it was already clear that he doesn't understand the field. I tried to demonstrate the fallacy using a reductio-ad-absrudum argument, but it seems that he's never been exposed to power-series and transforms of any form, and the argument escaped him. Oh well. I wonder whether this level of mathematical sophistication (or lack thereof) is partly responsible for the current state of software programming. It definitely seems to help; the Russian- and Indian- educated candidates we interview as a group are definitely better prepared than their American-educated counterparts
From: Robert C. Martin on 11 Jun 2005 22:08
On Sat, 11 Jun 2005 08:43:08 +0200, "Ilja Preuý" <it(a)iljapreuss.de> wrote: >CTips wrote: >> topmind wrote: >> <snip> >>> OO is good for .... shapes. >>> >> >> Not really. Anytime someone comes up with the shapes example, ask them >> how they would add the method: >> >> class shape { >> // true if object has any points in common with <B> >> boolean intersects(shape B); >> } >> >> See how quickly mind-lock sets in.... > >Why should this simple request cause any mind-locks??? The boolean problem isn't too hard to solve so long as you can represent all the shapes as equations. Determining whether or not the shapes intersect is then simply a matter of solving the equations. This is made much easier if the number of shapes is limited to polygons and conics. ----- Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 "The aim of science is not to open the door to infinite wisdom, but to set a limit to infinite error." -- Bertolt Brecht, Life of Galileo |