Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Patrick May on 18 Jun 2005 07:19 "topmind" <topmind(a)technologist.com> writes: > Perhaps I am just missing the real patterns, but I already have seen > hierarchies and sub-types crash and burn several times. Please provide examples from actual projects so that it can be determined whether the problems you claim to have seen are inherent in the paradigm or simply the result of bad design. 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: topmind on 18 Jun 2005 12:45 > > Perhaps I am just missing the real patterns, but I already have seen > > hierarchies and sub-types crash and burn several times. > > Please provide examples from actual projects so that it can be > determined whether the problems you claim to have seen are inherent in > the paradigm or simply the result of bad design. > > Sincerely, Taxonomies breaking down: http://www.geocities.com/tablizer/sets1.htm Java's class trees often have these anti-patterns: http://www.geocities.com/tablizer/trees.htm#flatten http://www.c2.com/cgi/wiki?MessyExceptionHierarchyAlwaysHappen Note that last one is of somebody else's opinion, not mine. And, I already mentioned the checking/savings radio ad. Another time I started to build a hierarchy for summary reporting and graphing of company divisions and departments. It turns out it was not a clean tree. Some categories summed in the same info, and then substracted it out later in goofy ways (they weren't my rules) I had to switch to sets, and everything was fine. They handled the almost-hierarchies well and also dealt with the goofy stuff too. Like I keep saying, sets are a great hedge. > > Patrick -T-
From: topmind on 18 Jun 2005 12:50 > > And, see how ugly the Visitor pattern is? Even some GOF (pattern) > > fans are otherwise embarrassed by it. > > Visitor is a means for non-intrusively adding behavior to classes > in languages such as C++ and Java that tightly bind methods to > classes. CLOS (the Common Lisp Object System) doesn't have this > issue, so the Visitor pattern is unnecessary. > > You are criticizing one particular language design choice, not an > inherent feature of OO. > Paul Graham, a Lisp fanatic, has suggested that just about *all* the GOF patterns reflect language weaknesses. > Sincerely, > > Patrick > -T-
From: topmind on 18 Jun 2005 13:13 > > > You have already been pointed to the publicly available > > > FitNesse. You have thus far failed to raise any issues with its > > > design or implementation despite claiming to have developed a Wiki > > > using your preferred approach. Please demonstrate how you would > > > improve this software by eliminating the use of OO techniques. > > > > I never claimed that I can objectively improve on it. I am only > > questioning suggestions that the OO version is objectively better > > than non-OO versions. > > Robert Martin has already described how the use of polymorphism > allowed a new storage mechanism to be implemented in a very short > period of time with no impact on existing code. You haven't shown how > you could achieve the same benefit as rapidly and cleanly using your > preferred techniques. It is a matter of probability. The upfront cost does not outweight the relatively minor chance of having to toss the database. It is all a matter of "decision math": http://c2.com/cgi/wiki?DecisionMathAndYagni Now maybe you question my change probability assumptions, but that does not mean that your alternative probability claims are valid. It just means we have *two* different unproven anecdotes about change probabilities. Thus, your proof is still not satisfied *even* if my estimates are unproven. It just means both our probability claims are sitting in evidence limbo. You seem to think that showing that mine are in limbo pushes yours *out* of limbo. This is not the case. Make sense? Besides, in that case one does not need polymorphism because there appears to be only one "driver" operating at a given time/installation in that scenario. One could create a procedural set of functions to operate on wiki messages, and simply swap them for new implementations. //-----wiki message module function getWikiMessage(...) {file_implementation...} function setWikiMessage(...) {file_implementation...} function searchWikiMessage(...) {file_implementation...} And then later if somebody wants to switch to a DBMS, just ship it with a DB implementation: //-----wiki message module function getWikiMessage(...) {db_implementation...} function setWikiMessage(...) {db_implementation...} function searchWikiMessage(...) {db_implementation...} Now if there are multiple drivers operating at the same time, the poly approach story may be different. However, a lot of this depends on language specific distribution and packaging metheds. Paradigms are not hard-wired to file systems and one-file-per-module that I know of. Files and DLLs are just an implementation detail. > Patrick -T-
From: Robert C. Martin on 19 Jun 2005 03:48
On 17 Jun 2005 20:50:37 -0700, "topmind" <topmind(a)technologist.com> wrote: >> >Or, how about: >> > >> > qr = query("select * from employees") >> > while (row = getNext(qr)) { >> > executue(row.strategyName & '()'); >> > } >> >> Same differences, that's just a manual implementation of something an >> OOPL will do for you automatically. > >What is "manual" about it? It can be simplified by making a >generic/library function for such: > > executeStrategies(entityName, strategyColumn) > .... > function executeStrategies(entity, col) { > qr = query("select * from " & entity); > while (row = getNext(qr)) { > executue(row[col] & '()'); > } > } > >It is hard to get more "automatic" than that. And Lispers do similar >things with ess-expressions all the time. Think of it as ad-hoc instead of part of a language syntax. Don't you think that you might benefit from language features that automatically defined, maintained, and invoked those vectors? >> >> So you give up? Or do you try to find regularity within the chaos. >> In many cases that regularity really is there. >> > >As described under the new "Change Patterns" sub-topic, I disagree. >If there *is* lasting regularity, it is NOT subtyped shaped. Yes, I've heard that assertion before. There is nothing in my experience that I can use to validate it. Since I have repeatedly created object oriented structures that are resilient to change, I must conclude that your fear regarding the shape of change is unfounded. Indeed, I don't think the argument even makes sense. The issue is not whether changes can be expressed as subtype hierarchies. The issue is whether or not the software can be partitioned to be admissive of change through the use of polymorphism. Those are two very different things. ----- 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 |