Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
Prev: Use Case Point Estimation
Next: Association Class
From: Patrick May on 12 Jun 2005 03:53 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: > > Outstanding, you finally have the opportunity to demonstrate > > the advantages of your preferred programming approach over OO in > > the context of a real application. Robert Martin has already > > provided a link to his implementation -- let's see yours. > > Unfortunately, I don't want to release it public because I want some > security through obscurity. I might release snippets though. There > are plenty of existing wiki's implementations anyhow, and my > approach does not significantly differ than them (although I feel I > factored better than some of those I looked at). Security through obscurity is no security at all. As you note, there are a number of Wiki implementations extant; it seems unlikely that making the code to yours available would cause you any harm. At the very least, you could support your claims regarding polymorphism by publishing enough of your code to allow comparison with FitNesse. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
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 |