Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Robert C. Martin on 19 Jun 2005 07:28 On 17 Jun 2005 20:54:26 -0700, "topmind" <topmind(a)technologist.com> wrote: >>> An array of function pointers. That has been around long before OOP. >> >> An array of function pointers *is* OOP. Or rather OOP is discipline >> imposed upon tables of pointers. > >In that case OOP was invented in the 40's, not 60's. I don't know about the '40s. But certainly people were exploring vector tables in the '50s. The discipline that Simula and Smalltalk imposed upon those vector tables is what has become known as OO. >But, I don't think >your definition is the concensus among OO proponents. I agree that it is not; but then these folks aren't familiar with the history. The fact that OO was born from a decision to move an Algol function stack frame to the heap, is not comforting to those who want OO to be a philosophy of life. Be that as it may, OO has it's beginnings in vector table management; and even today it's prime benefits come from the disciplines that OOPLS impose on vector table management. > And if OO is more >"disciplined" than relational, I will eat the lint in my socks. Then you should be prepared to start picking your feet in Poughkeepsie. ----- 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: topmind on 19 Jun 2005 12:56 > > >> >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? Perhaps, but actually I don't need that construct very often. This is because most pieces of logic end up being controlled by multiple factors, not a single factor (strategy name). It is the "multiple interweaving orthogonal factors" issue again rearing its ugly head. The "manual" approach "degenerates" better to handle multiple factors when they come. > >> > >> 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. I could say the same about your view. Then again, if it ended up like the Visitor pattern, you would call it "elegant" and I would call it a mess. In other words, we would score the impact of change differently for the same code. > > 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. I never claimed poly cannot express stuff. With enough cajoling and duplication, trees or sets of trees can in theory represent *any* graph. The issue is the maintenance and cognative effort a developer has to go thru to use such a structure. I think we agree on that point. I just don't see many real-world factors that *herd* changes into patterns favored by poly. Managers, marketers, customers, and owners usually don't care about tree purity, so their decisions are not going to be a source of pro-tree changes. I have a question of you. If for the sake of argument the changes *are* random, do you still think polymorphism would simplify changes? > > ----- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 19 Jun 2005 13:00 Robert C. Martin wrote: > On Wed, 8 Jun 2005 11:50:50 +0100, Gerry Quinn > <gerryq(a)DELETETHISindigo.ie> wrote: > > >> Polymorphism will help fold redundancies together - if any. > > > >It can help that. Sometimes. As 'topmind' observes, it can also trap > >you somewhere you don't want to be. > > Polymorphism is a tool, not a solution. Topmind rails against the > tool because there are cases where it doesn't work well. I, for one, > am glad I have the tool. > I don't dispute there are places where it simplifies stuff. However, many in the OO community greatly exaggerate its applicability and OO books rarely have any kind of disclaimer. Such white-washing may come back to bite OO hard. > > > ----- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 19 Jun 2005 13:05 > >> The bottom line for OO is that it is a technique for > >> managing dependencies and reducing coupling; and > >> the primary tool for achieving that is polymorphism. > > > > And I invite you to demostrate that with code examples > > outside of "device driver" examples. (Unless you can > > argue that most software issues can be effectively > > modeled as or like device drivers.) > > > Lord knows, Uncle Bob may be guilty of many things, but failure to provide > code samples is not one of them. Why don't you pick one of the articles > from his web site, or take a fragment from one of his books, and tell us why > you think his approach is misguided? I did. I debunked[1] bank account "types", employee "types", and showed a cleaner way to manage a combinatorial lake of modem driver parts. > > Regards, > Daniel Parker [1] Or at least raised key questions -T-
From: Juancarlo Añez on 19 Jun 2005 13:08
> Be that as it may, OO has it's beginnings in vector table management; > and even today it's prime benefits come from the disciplines that > OOPLS impose on vector table management. I had the opportunity to study and program in Simula while studying at the university some twenty years ago. I read the whole "Simula Begin" book back then, and I don't remember there being any mention of "vector tables" (shouldn't that be "function tables"?). Quite to the contrary, all of Simula was about approaching programming from a different perspective. They wanted to do software simulations (hence "Simula") and they found the abstractions provided by existing programming languages lacking. I don't think I even heard about vector tables until I read about it in the 1989 Turbo Pascal 5.5 documentation sections about the low level stuff. BTW, TP 5.5 made OO mainstream for many programmers (TP had probably about a million programmers then). The previous attempts, like Smalltalk or Actor, were not "professional enough" in that they consumed too much computer resources and were too cumbersome to use on a PC to even be considered as an option. Juanco |