Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Alan Gauld on 10 Jun 2005 18:41 "Phlip" <phlip_cpp(a)yahoo.com> wrote in message news:Vx0qe.6494$_A5.5126(a)newssvr19.news.prodigy.com... > My word fOO is easy to apply, because it's narrow. Find the jump-table, or > equivalent, and we got fOO. > > My word fOO is distinct, meaning any two engineers can agree independently > whether a system has my fOO. > > The easy and distinct properties together lead to a third property. Because > fOO relates to very important programming topics, and because two engineers > who know my definition of fOO can say "fOO" to each other all day and know > what each other mean, that makes my definition useful. > > Definitions should be easy to apply, distinct, and useful. > > In terms of "correct", what is the difference between my word "fOO" and this > "OO" word you use? You just described the difference. Your definition is much narrower than OO. OO has een applied to many different things from menu systems to graphics to business analysis therefore it cannot be defined purely in terms of programming terms. Even OOP has many subtly different definitions and although I may dislike many of them, and like your definition of fOO, I cannot pretend that fOO defines OO. Alan G.
From: Leif Roar Moldskred on 10 Jun 2005 18:49 "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. You can't ask if "this software is better than equivalent software written without OO" -- if the software is equivalent than by definition it isn't better. You'll have to ask if this software was cheaper/quicker/easier _to make_. > 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). 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. > 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. -- Leif Roar Moldskred
From: CTips on 10 Jun 2005 18:57 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....
From: topmind on 10 Jun 2005 19:05 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. 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). [....] > > > 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). > > 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. > > > 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. > > -- > Leif Roar Moldskred -T-
From: topmind on 10 Jun 2005 19:11
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- |