Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 21 Jun 2005 00:58 Phlip wrote: > coeval wrote: > > > When one says the main concept in OO is polymorphism, let me I have > > some doubts. > > Have you read the book /Design Patterns/? The authors held themselves to the > laudable goal of citing 3 real-life projects per pattern. > > Each had more, of course. Those tend to be the domain of "systems software", an area already over-explored with OO. Many of us want to see more business-oriented examples rather than writing text editors and device drivers. > > > I read lot of books about OO to improve my skills but most of the time > > the real world is completely different. > > The "real world" is the problem. > > Plenty of OO tutorials accidentally start with "OO works best because you > can model the real world", or similar. This is heinous verbiage for one > simple reason: If we discuss which of two OO models is better, saying "mine > is better because it models the real world" adds nothing to the > conversation. > > The OO model with the simplest implementation and least redundancy is > better. The Real World _never_ obeys that guideline. But sometimes the best > way to replace redundancies with flexibilities is with virtual methods. > > You use OO every time you open a file handle and write to it. The target > could be a disk file, a console, a printer, etc. That's polymorphic behavior > encapsulated behind an interface: OO. Again, this is the device-driver/systems-software domain. There is a derth of "good" examples from the business domain. I say "good" because the few there are tend to have unrealistic, oversimplistic assumptions behind them. The authors appear ignorant of "real world" custom business software developement and the change patterns surrounding it. [snip] -T-
From: Christer Ericson on 21 Jun 2005 01:29 In article <1119286127.079006.327060(a)g49g2000cwa.googlegroups.com>, apalala(a)gmail.com says... > [...] As big as Dijsktra's proving structured programing was complete. Are you refering to that sequencing + selection + repetition is complete with regards to expressing all algorithms? If so, that result is due to Böhm and Jacopini (1966), not Dikjstra. > As big as Hoare's concept of "monitor", which provided a new insight > into parallel programming That should read "Brinch Hansen's concept of 'monitor'." See Chapter 6 of Brinch Hansen's memoirs for the details of Hoare appropriating the concept from Brinch Hansen (page 112- 113 specifically): http://brinch-hansen.net/memoirs/chapter6.pdf -- Christer Ericson http://realtimecollisiondetection.net/
From: coeval on 21 Jun 2005 06:39 I was involved to develop a control quality application for a major company in early 90's. We used C and a C++ pre-processor from the Irish company Glockenspiel, and GUI library CommonView. It was my first object-oriented application and I was at the "top of my art". But... the development was painful, senior management wanted to have a complete objects-oriented application, so we ended by re-inventing the wheel. Btrieve , an ISAM library, was wrapped simulating a database. 100,000 lines were produced, no design, no documentation. After 6 years manpower, two project leaders sacked, the application went live and in maintenance.... Few times after we won a fixed price contract for large music company, surprisingly the application was developed with Clipper/DBASE, management directors were reluctant to use the new object state-of-art system. Just 3 people and 2 months after the application was in UAT, I was flaggerbasted how fast the application was developed. Clipper/Dbase built-in functions were far more better than in-house C++ classes/methods. On 2 days developers designed all reports, when I had to do the same on my "object-app" I was doomed. I ended up writing a Query Object Framework (qof) simulating SQL queries.... Arrgg!!! That is the real world, even today, after almost 15 year nothing has really changed. Don't trust methodologist, refactorist, Gof, pattern, anti-patterns, distilled stuffs.... just go back to the basic: maths, logical sets. Use a top-down procedure to refine your design without thinking about the programmatic language you are going to use. Harvey
From: Robert C. Martin on 21 Jun 2005 08:24 On 20 Jun 2005 09:41:01 -0700, "topmind" <topmind(a)technologist.com> wrote: >> >> >I have a question of you. If for the sake of argument >> >the changes *are* >> >random, do you still think polymorphism would simplify changes? >> >> Yes, because polymorphism help me to decouple. Decoupled modules are >> easier to change. >> > >First of all, I thought you agreed that not all coupling is bad >(remember the suitcase analogy?). Thus less coupling is not inherantly >good or bad. Your line of reasoning appears inconsistent on this. > >It seems coupling is "good" if it helps simplify changes, and "bad" if >it does not. But this gets back to probabilities of possible change >patterns. Of course. The reason I stress DE-coupling is that it is intrinsically harder then EN-coupling. I can couple two modules simply by having one mention the name of the other. But Decoupling two modules that are already coupled takes a bit more skill, and tools like polymorphism help a lot. Not all coupling is bad. But deciding which couplings are good or bad is not always evident at first. Also, as the software matures couplings that used to be valuable may become more and more harmful. So I need good tools to help me break and re-route existing couplings. >Copy-and-paste actually *reduces* coupling because it lets things be >independent, for example. I disagree, rather strenuously. Copy-paste does not reduce coupling, it hides it. An algorithm that is pasted into a dozen different modules creates a bizarre coupling between those modules. Even though the modules don't know about each other, they have a reason to all *change* together. Each instance of the algorithm is NOT independent of all the others. A change in one almost certainly implies that the change must be made in all the others. Using the Template Method or Strategy pattern to resolve this kind of duplication is almost always better than allowing the individual pastings to co-exist. >So, let's focus on change impact. Can you answer in terms of change >impact instead of "coupling"? That would be helpful. If you would >rather stick to "coupling", then first we need to clarify what kind of >coupling is good and what kind is bad. No, we don't have to do that. Any freshman software developer knows that it is easier to change module X if no modules depend upon it; and that it is harder to change module Y if many other modules depend upon it. Managing couplings is a matter of moving volatile code into modules that nobody depends upon; and moving non-volatile code into modules that many modules depend upon. >How about we explore a code change scenario. I have five case statement >items (occuring once) and you use polymorphism instead. Now suppose the >change is that the items become non-mutually exclusive (yep, that word >again). Do you claim the total change effort for poly will be less than >what it would be for the case statement? I don't know. How many times does that switch statement appear? If it's once, then the difference between switch and polymorphism will be similar, and a bit weighted towards the switch. If there are 11 instances of the switch statement, then the difference will be dramatic and strongly weighted towards polymorphism. ----- 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: Robert C. Martin on 21 Jun 2005 08:38
On 20 Jun 2005 16:44:33 -0700, "coeval" <hvfrench(a)gmail.com> wrote: >When one says the main concept in OO is polymorphism, let me I have >some doubts. > >I read lot of books about OO to improve my skills but most of the time >the real world is completely different. >I suggest OO authors and OO evangelists should dive in 100,000 lines of >Java/C++ code, written by numerous OO-ish programmers, to fix bugs, >defects, performance issues and misconceptions. Been there. Done that. And with a *lot* more than 100,000 lines of C++. And I say that the main concept of OO is polymorphism. Without polymorphism OO is simply an argument between: f(o) and o.f(). ----- 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 |