Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Phlip on 21 Jun 2005 10:08 [In Google Groups, please hit Preview then Edit, to pull in the replied-to text. Then trim that down to the author and context.] coeval wrote: > But... the development was painful, senior management wanted to have a > complete objects-oriented application, so we ended by re-inventing the > wheel. Management by magazine? Did they provide OO training? Did they permit you to iterate your design? Or did they order your "lead architects" to convert a huge specification into a complete "OO" model before implementing any of it? > 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.... Okay. No up-front design. Y'all were ordered to code-and-fix, /and/ to "make it OO". > 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.... I'm confused. Y'all were not doing those things, so why blame them? > Use a top-down procedure to refine your design without thinking about > the programmatic language you are going to use. Both the situations you describe, and that suggestion, delay feedback from decisions. If you design without feedback, then wait a long time to learn if your design is truly flexible, changing that design will be very hard. -- Phlip http://www.c2.com/cgi/wiki?ZeekLand
From: Isaac Gouy on 21 Jun 2005 10:34 Robert C. Martin wrote: > >> >Of course, the words of the creators of Simula will be of no comfort > >> >to prevaricators who cannot deal with the fact that OO did not appear > >> >from some programmers hacking around with Algol-60 and discovering > >> >things by mistake (a s/w Penicillin in effect) ... *** > >> > >> Steve, there is a difference between accusing someone of being > >> incorrect, and accusing someone of being a liar. The first is > >> civilized, and the second is libelous. > > > >Robert, I was puzzled by your reaction (in English prevaricate is not a > >synonym for lie) - so after checking the OED, I looked in Websters and > >found the definition I expected "to turn aside from, or evade, the > >truth; equivocate" and then a secondary meaning "to tell an untruth". > > > >Maybe something was lost in translation between English and American. > > Perhaps. When I saw Prevaricator, I read "liar". I'll leave it to > Steve to clarify. Robert, you mis-read a word and started talking about libel - that really takes the air out of a discussion.
From: topmind on 21 Jun 2005 12:32 Robert C. Martin wrote: > 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. So you claim > > 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. So you claim > > >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. But now you are talking about something that is not objectively measurable, at least not from looking at the code. There are no coded links between the two copies. True, they *may* change together, but they also may not. Only an analysis of change impact can answer that, not looking at the code (before the change). If you start talking about "conceptual coupling" rather than a link found in actual code, then we probably won't get anywhere. It is like trying to nail Jell-O to a cloud. If you want to continue to push the "coupling" notion, you are going to need more precision in measurement and terms. This sort of reminds me of debates about whether Smalltalk has "types". Many concluded that the "types" are in the minds of developers rather than in Smalltalk code or interpreter. That may be the case, but it sure makes it hard to say anything objective about "types" and Smalltalk. Perhaps we should make a distinction between objective coupling and conceptual coupling. Objective coupling is a link/reference found in the code. One can print the code and circle the coupled items/names and draw lines between the code parts. > > 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. Note that I was not promoting copy-and-paste. I was only showing how measuring *objective* coupling does not by itself lead to more change-friendly code. Copy-and-paste objectively decouples the copies but does not necessarily improve change-friendliness of the code. > > >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; No, we've already seen that (objective) de-coupling by itself is not always good, as the copy-and-paste illustration shows. Perhaps you are measuring from the point of "module" instead of the point of "change request". Making one module easier to change may not necessarily make the total change effort easier, as copy-and-paste (C&P) shows. If you C&P to make module A and module B, then a change that affects both will require visiting both modules, whereas factoring perhaps would result in only having to visit one. Thus, you are correct at the micro level but not necessarily the macro level. The goal should be to reduce *total* change effort, not individual modules. > 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. Unfortunately, *everything* is volatile in my domain. Actions and entities are as stable as anything, but still not guaranteed in any way. > > >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. You assume that switch statements that start out the same will also end up the same down the road. Again, I asked you if you would hold the same view if the changes were random as part of a thought experiment. But dup case lists that grow in lock-step are *not* random. My experience is that they *do* tend to drift apart over time. I tend not to use a lot of case statements because of such volatility. If there is mass duplication and they stay the same, then generally it is something that should be put into a database table, not code. Two common changes to case lists are loss of mutual-exclusiveness (already discussed) and the introduction of other orthogonal factors that affect the dispatching of behavior. Most dispatching of behavior is or can easily be affected by multiple orthogonal factors down the road. Polymorphism incorrectly assumes one and only one dispatching factor is stable. Stepanov complained about this also in his famous interview. > > > ----- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 21 Jun 2005 14:16 Robert C. Martin wrote: > On 20 Jun 2005 21:58:51 -0700, "topmind" <topmind(a)technologist.com> > wrote: > > >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. > > There is no predilection towards systems software amongst the design > patterns. They are simply patterns that have recurred in a wide > variety of applications including business, graphics, text > manipulation, etc. Can you name business examples of their usage, and how they "better" than procedural/relational alternatives? I know there are business examples of Strategy, but there are non-OO equivalents (I already gave links to my webpage on that). But in practice Strategy does not fit the patterns of change either in my observation. Multiple interweaving orthogonal factors tend to gum them up also. And removal of mutual-exclusiveness barfs on them too. A common example is a "notification strategy" such as whether somebody wants to be notified by email, paper mail, or phone. Howevever, it is perfectly plausible for a customer to want more than one. The p/r change would generally be the division of the "delivery method" code into independent columns: BEFORE: table: foo ------------ fooID .... deliveryMethod (E=email,M=paper-mail,P=phone) AFTER: table: foo ------------ fooID .... byEmail (Boolean) byPaperMail byPhone The case statement that delivers such would likely be changed into 3 IF statements. Not a lot of code would need to be moved around, it is mostly just a change to IF's in the Delivery module. I would be interested to see OO improve on that without foreknowledge or "pre-engineering" for such change. Do you know of business examples for Visitor? > > ----- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: Patrick May on 21 Jun 2005 16:09
"topmind" <topmind(a)technologist.com> writes: > > > Perhaps I am just missing the real patterns, but I already have > > > seen hierarchies and sub-types crash and burn several times. > > > > Please provide examples from actual projects so that it can > > be determined whether the problems you claim to have seen are > > inherent in the paradigm or simply the result of bad design. > > Taxonomies breaking down: > > http://www.geocities.com/tablizer/sets1.htm This is not an example drawn from a real project. > Java's class trees often have these anti-patterns: > > http://www.geocities.com/tablizer/trees.htm#flatten This is not an example drawn from an actual project (or even actual Java APIs). > http://www.c2.com/cgi/wiki?MessyExceptionHierarchyAlwaysHappen Java is one, not particularly elegant, implementation of a particular subset of possible object oriented languages. Criticizing it is not equivalent to criticizing object oriented techniques in general. > And, I already mentioned the checking/savings radio ad. A radio ad is definitely not a real project. Please provide detailed examples from actual real-life projects where you have "seen hierarchies and sub-types crash and burn several times." If you cannot, there is no reason to take your claims about the technology seriously. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML) |