Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Laurent Bossavit on 12 Jun 2005 04:08 > Again, you describe "edits" in terms of a hierarchical taxonomy Nope. The type Edit can be an interface in Java terms, or a protocol in Smalltalk terms. No inheritance required, no mutual exclusion implied. I have described the type Edit as an "umbrella term"; an abstraction. One object can perfectly well be an Edit and several other things as well. What matters is that there are a number of classes of objects which play the role of "Edit" in a given computation, and we can say everything we have a need to say about that role in one and only one place. We say nothing about the roles that can played by the very same objects in other computations. Polymorphism is a well-known phenomenon in molecular biology. A protein folds up for form a "slot" on its 3D surface. Another protein may fit into the first only if it has the proper shape for that slot, called a binding site. Now, more than one protein can have the proper shape to fit into that slot. This mechanism is fundamental to, for instance, vaccination. In other words, Nature invented polymorphism ages before we rediscovered it in software systems. The designs Nature invents tend to be "smart moves", structures that are so effective that even the undirected, relatively inefficient design process that is evolution will inevitably stumble on them. Laurent
From: Ilja Preu� on 12 Jun 2005 03:02 Robert C. Martin wrote: > 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. Well, yes. To me, the interesting question here isn't the algorithm of calculating the intersection of two shapes, but why requesting to *put the operation into the shape class* should cause any mind-lock. I assume that the underlying algorithm wouldn't need to change much regardless of where we put it... Regards, Ilja
From: Ilja Preu� on 12 Jun 2005 03:14 Robert C. Martin wrote: > The tougher one is: > > Shape intersection(Shape s); > > That requires a generic shape that can represent any shape at all. Well, it depends on the other operations on the Shape class, I think. (I might just not understand what you mean by a "generic shape", though.) Imagine that the only other operation we need is a contains(Point). For that, we wouldn't even need to calculate the intersection Shape - we could just remember the original Shapes and delegate to them (the intersection contains a point if both original shapes contain the point). I think this shows very nicely that the question "are shapes good to apply OO on" is nonsense - it simply depends on the more detailed circumstances wether and how you would apply OO to the problem. Kind Regards, Ilja
From: Daniel Parker on 12 Jun 2005 06:55 "topmind" <topmind(a)technologist.com> wrote in message news:1118553409.435497.32430(a)z14g2000cwz.googlegroups.com... > > >> >> You make claims all the time and have no proof. >> > >> > Like what? >> >> Like (referring to RCM) "But all his examples are device drivers" >> >> Like {referring to me) "you were the one bragging about how great >> polymorphism is," >> > Those are claims about debate issues, not paradign claims. > Not even that. They are simply statements that are not true. Regards, Daniel Parker
From: CTips on 12 Jun 2005 07:27
Robert C. Martin wrote: > On Fri, 10 Jun 2005 18:57:21 -0400, CTips <ctips(a)bestweb.net> 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.... > > > That one is not so hard. Simply algebra can solve it without too much > difficulty (I've done it). The tougher one is: Nah, the problem isn't the implementation. Its the fact that you have to (in general) have to write a separate function for each _pair_ of subclass types. Thus if you have the following sub-classes of shape: square, circle, koch_snowflake you will need to implement functions square_with_circle square_with_koch_snowflake circle_with_koch_snowflake. Now if you introduce another shape, say a mandelbrot set. Then you need to introduce another 3 functions: {square,circle,koch_snowflake}_with_mandelbrot_set This means that you need to know _ALL_ other shape sub-classes out there before you can actually implement the function intersects(). [I have deliberately picked some fractal shapes so that a certain mathematical ignoramus (not you) doesn't start quibbling; however I am _NOT_ certain that intersects() is actually computable for both the koch snowflake and the mandelbrot set.] |