Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Robert C. Martin on 11 Jun 2005 22:20 On 10 Jun 2005 13:31:00 -0700, "topmind" <topmind(a)technologist.com> wrote: >> And bound to the RDBMS. > >You OO'ers always make that sound like a bad thing. Youses are >DB-phobics. I don't want to be bound to OO, can we wrap that away too? >(I agree that the DB tools are sometimes lacking in implementation and >portability). > >> If we had done that, our tests would be too >> slow, and we would have to ship the system to our users with some kind >> of RDBMS attached. > >My RDB-bound wiki was not "slow". You misunderstand. I run over 1,000 unit tests, and over 100 acceptance tests on the system. These tests combined take about 90 seconds to run (on a bad day). The reason for this speed is that I use the in-memory version of the page object. > >Anyhow, one can do something like this: > >function getWikiArticle(articleID) { > if (sys::driver==RDBMS) {.....} > elseif (sys::driver==Files) {.....} > elseif (sys::driver==RAM) {.....} > else {error()) >} // end-function True, one could do that. However, that makes a generic function (getWikiArticle) depend upon three different implementations. That kind of coupling is unfortunate. I'd rather have the getWikiArticle function not know about RAM, RDBMS, and FILES, and that's what polymorphism gives me. >But I would really like to see poly in business-modeling issues, not >storage and EXE distribution issues. Then look at the way FitNesse handles everything else. Or look at the payroll example in the PPP book. (The library likely has a copy. If not, a local Barnes and Noble will have one.) > >> So if you are using ODBC or >> JDBC, you are using OO techniques to talk to your database. > >Perhaps. But that does not mean polymorphism is good for everything. It's good for many things, not for everything. It's use is situational, not specific to particular domains. There are situations within every domain in which polymorphism is both useful and not. That includes drivers, persistence, telecommunications, business rules, guis, etc, etc. Wherever dependencies need to be managed (which is just about everywhere) there is a potential for polymorphism to facilitate that management. ----- 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 17:36 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 ? A series of curves can be used to draw a circle. Jeff Brooks
From: topmind on 11 Jun 2005 23:06 > You make claims all the time and have no proof. Like what? Even if I did, does that give you license to also be an idiot? -T-
From: topmind on 11 Jun 2005 23:25 Jeff Brooks wrote: > topmind wrote: > > > Leif Roar Moldskred wrote: > > > >>"topmind" <topmind(a)technologist.com> writes: > >> > >> > >>>Huh? I was hoping to see demonstrations of polymorphism making software > >>>better (by whatever metric you propose) in something besides the common > >>>textbook domains. > >> > >>That's like asking if cars made with metric screws are better than > >>cars made with imperial screws. OO doesn't add anything to the > >>_software_, so if you're looking to find the advantages of OO _in the > >>software_ you won't find it. OO adds advantages to the _development > >>process_ and that's where you'll have to look for its advantages. > > > > Fine. Describe precisely how it does this. I am not dictating to you > > what metrics to use to compare OO to whatever, I am *asking*. Just be > > clear about your metric(s) and how you arrive at it. > > What metrics did you use to come to your conclusions? > > > If you brag about OO, then it is your responsibility to produce > > clear-cut (or at least good) evidence of it helping whatever the hell > > you claim it helps (besides device drivers). > > We've been through this before. > > OO is the standard right now. That is hogwash. Most developers do not use OO, just OO languages. And, even if it was, being popular is not the same as being good. Otherwise Microsoft is the Nervana of perfection. > > If the OO guys don't prove their point OO will remain the standard. If > you don't prove your point OO will remain the standard. > > If you prove your point then things may change. You may not like it but > if you don't prove your point then you lose the argument by default. > > >>The customer's aren't the ones who are going to change the code -- we > >>are, _on behalf of the customers_. For that reason, we don't choose > >>our OO structure arbitrarily. We choose it _deliberatedly_, after > >>analysing the requirements, including the requirements for futere > >>change and additions. Your point about "arbitrary classification" is a > >>straw man, because the classification _isn't_ arbitrary. > > > > > > Well, this will probably turn into a language battle over what > > "classication" means. > > > > But generally if you use a tree to represent classifications of > > products (such as bank accounts), you will have difficulty forcing > > future changes to fit into a nice tree. Any classification *can* be > > turned into a tree if you try hard enough, but it is should be an > > excercise left only for the worse prisoners at Guantimo Bay. > > > > As a reader excercise, try to create a hierarchical classification of > > people and add about 20 traits/factors onto it. When you are done with > > that, then mow your lawn with tweazers. > > That might be a valid point if all OO models require deep > classifications trees but OO doesn't so you point is meaningless. If they don't, then the alternatives are also simple. And how do you know up front whether classifications will remain simple forever? OO is supposed to make software easier to change, but you appear to refute that claim. > > >>>I assumed being change-friendly was one of the bragging points of > >>>polymorphism. If not, then please state your measurements of > >>>betterment. > >> > >>For the purpose of this argument? "Cheaper/easier/quicker to make," > >>for reasons explained above. > > > > The reasons were not clearly explained. Textbooks tend to only show > > change scenarios that favor polymorphism, conveniently skipping those > > that don't. > > Like the way you try to find a few cases where classification trees > aren't the perfect model and ignore that in the majority of cases it > works fine?! Again, if we are only talking about trivial hierarchies, then most approaches will be adequate. If nothing changes and it all stays simple, then it ain't matter either way. OO fans often brag about how OO allegedly scales in "big applications". You seem to be contradicting that. The more complex something becomes, the more likely it is to drift away from a clean tree. Classification philosphers have discovered this centuries ago. Like I said earlier, even many existing OO gurus agree that trees are limited to rely on often. They are just not as vocal as I am about it. > > Jeff Brooks -T-
From: topmind on 11 Jun 2005 23:32
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > > You may investigate this by looking at the source code of this > > > particular program. You can download it at www.fitnesse.org. > [ . . . ] > > Regarding your wiki example, I actually wrote my own wiki about 5 > > months ago. > > 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). > > Sincerely, > > Patrick > -T- |