Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Jeff Brooks on 11 Jun 2005 13:13 topmind wrote: > And right off the bat in this link: > > http://www.ratio.co.uk/white.html > > They define a hierarchy of bank account types. I have ranted against > this before. To satisfy how customers really want stuff, you just > cannot use hierarchies. Customers want a smorgishbord, not hierarchies. > See: > > http://www.geocities.com/tablizer/mellor.htm#customerplans Classification hiearchies don't need to be used to model everything in OO. Your argument in this case is very weak. Jeff Brooks
From: Jeff Brooks on 11 Jun 2005 13:33 topmind wrote: > Leif Roar Moldskred wrote: > >>"topmind" <topmind(a)technologist.com> writes: >> >> >>>And right off the bat in this link: >> >>So? You were demanding examples of OO on the web that wasn't device >>drivers; not examples of OO on the web that was likeable to you. (I >>very much doubt the latter exists anywhere.) > > Huh? I was hoping to see demonstrations of polymorphism making software > better (by whatever metric you propose) in something besides the common > textbook domains. There have already been a few examples posted. Read them. >>(And from my experience, customers want a sysetm that _works_ and >>doesn't give a damned about how you make it work as long as it doesn't >>involve grand treason -- unless they can claim plausible deniability >>in which case they don't care about the how at all.) > > Software is generally going to be more change-friendly if it fits the > pattern of future changes. If the customers don't give a damned about > your internal hierarchies, then using hierarchies is probably not a > good change-friendly bet (unless you want to force them to live by your > arbitrary classification system and let them vote for your competitor > with their feet). That's an illogical argument. Do you think if a customer doesn't give a damn about the structure of a procedural program that means the structure won't affect the future maintainability of the software? >One would just spend a lot of time reshuffling the > tree to handle new requests and/or new combinations of requests. I want > a bank account that is BOTH savings AND checking perhaps, and to switch > each such feature on and aff as desired. Are you really gonna create a > Cartesian Explosion of sub-classes for each feature combination > (existing and new)? That's an illogical argument. The problem would only exist if you had to model everything as a single rooted classification tree. That isn't true so your argument is meaningless. > I assumed being change-friendly was one of the bragging points of > polymorphism. If not, then please state your measurements of > betterment. How did you measure that polymorphism is worse? Jeff Brooks
From: Jeff Brooks on 11 Jun 2005 13:43 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.... Model shapes as a series of lines/curves then test for intersections on the lines/curves that make up the shapes. This was really easy to solve?! Why do you think it's a problem? Jeff Brooks
From: Jeff Brooks on 11 Jun 2005 13:52 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. 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. >>>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?! Jeff Brooks
From: Jeff Brooks on 11 Jun 2005 13:56
topmind wrote: > Well, actually there are a lot of shape conundrems floating around, > such as the square-isa-rectangle classification problem. I was just > trying to mentally move people beyond the common textbook examples and > didn't mean to formally endorse shapes. -t- How do you explain that there is OO software that can process shapes if OO has problems with it? Jeff Brooks |