Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Robert C. Martin on 22 Jun 2005 17:26 On 21 Jun 2005 03:39:36 -0700, "coeval" <hvfrench(a)gmail.com> wrote: >That is the real world, even today, after almost 15 year nothing has >really changed. Unfortunately you are equating the rather common practice of over-OO-design, with OO. Too many people do exactly what you described. They bloat their designs, and load them full of this or that OO model, without any good reason. They read the GOF book, or some other book and they simply think that you are SUPPOSED to always build big horrendous abstract models. You aren't. You've thrown the baby out with the bathwater. OO is not about big bloated models of over abstracted frameworks and wrappers. OO is about simple decisions to break harmful or inconvenient dependencies. >Don't trust methodologist, refactorist, Gof, pattern, anti-patterns, >distilled stuffs.... Good advice. Trust your experience, and make sure you experience a lot of things. > > just go back to the basic: maths, logical sets. Going back to basics is a good idea. Math, logical sets, coupling, cohesion, information hiding, separation of concerns, structured programming, etc. >Use a top-down procedure to refine your design without thinking about >the programmatic language you are going to use. Generally a useful procedure, so long as you don't put too much faith in the structure that results. ----- 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 22 Jun 2005 17:30 On 21 Jun 2005 07:34:35 -0700, "Isaac Gouy" <igouy(a)yahoo.com> wrote: >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. I'll let Steve decide if I mis-read the word. Still waiting to hear. ----- 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: Patrick May on 22 Jun 2005 18:08 "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. > > The "labcoat" example is real. The "lab coat example" is a single sentence describing one rejected taxonomy. It is not an example of polymorphism "crashing and burning" on 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). > > Do you deny that Java API's sometimes follow that pattern? You are squirming again. The issue isn't particular Java implementations, it is your claim that you've "seen hierarchies and sub-types crash and burn several times." Prove it. > > > And, I already mentioned the checking/savings radio ad. > > > > A radio ad is definitely not a real project. > > It was a real ad. It was not me who implimented a dual account, but > *somebody* in real life did. It is not an example of you, personally, seeing "hierarchies and sub-types crash and burn several times" on real projects. The last time you infested this newsgroup you made it clear that you had only worked on simple CRUD and reporting systems and that you had no paid experience with OO languages. Has this changed? If so, let's see your real examples to back up your claims. 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)
From: Leif Roar Moldskred on 22 Jun 2005 18:51 "topmind" <topmind(a)technologist.com> writes: > Leif Roar Moldskred wrote: > > "topmind" <topmind(a)technologist.com> writes: > > > > > The topic is polymorphism, not necessarily OO in general. Perhaps that > > > case can be considered a misuse of polymorphism. However, there are no > > > concensus, or even carefully worded individual guidelines for when to > > > use poly and when not to. > > > > Of course not. You can't do design by rote; there are no simple > > guidelines because developing software is not a simple thing. You use > > polymorphism when it makes sense and when it improves the legibility > > and the design of the system. > > > > You might almost as well ask for a "carefully worded individual > > guideline" for when an artist should use the colour red. > > Well, I generally disagree. Procedural development using RDBMS is > fairly strait-forward in many or most shops: Normalize your schemas (to > reduce info redundancy), Except, of course, that it is not that simple. While normalised data gives better data integrety, it can give longer read times. Are you able to give "carefully worded individual guidelines" about when to keep which data normalised? > break the problem down into a series of > relatively-independent tasks/events, Right -- and you're able to give "carefully worded individual guidelines" for how and when to break a problem into sub-tasks? > and factor common functionality > into shared libraries or consider developing a declarative framework > using RDB tables. And you're able to give "carefully worded individual guidelines" as to how to factor out common functionality? > I don't always agree > with them, but speed issues are a side topic to some extent. Moores Law > will wipe out most of such issues anyhow in 50 or so years (assuming > comparable "big-O" scores). Three things: Moore's Law is an observed trait, and not a law of nature; at some point it will cease to be accurate. Secondly, Moore's Law that describes the increase in power of the CPU, and _not_ physical storage mediums, which is the main limiting factor for database access. The speed of hard-disks reads and writes have increased far less dramatically over the years. Thirdly, the point is moot anyway. Two equivalent systems, one written with OO methods and the other with procedural ones will have to read and write the same data to the backend database _anyway_, since they're supposed to do the same job. Unless one of them has done a right hatchet-job of the database access or uses the database needlessly, the speed of the database won't make a whit of a difference between the two systems. (You have been told this time and time again, so it can't precisely come as a shock to you; but it is just as easy to use relational databases in OO development as it is to use them in procedural development.) -- Leif Roar Moldskred
From: topmind on 22 Jun 2005 22:37
> > > > > > > The topic is polymorphism, not necessarily OO in general. Perhaps that > > > > case can be considered a misuse of polymorphism. However, there are no > > > > concensus, or even carefully worded individual guidelines for when to > > > > use poly and when not to. > > > > > > Of course not. You can't do design by rote; there are no simple > > > guidelines because developing software is not a simple thing. You use > > > polymorphism when it makes sense and when it improves the legibility > > > and the design of the system. > > > > > > You might almost as well ask for a "carefully worded individual > > > guideline" for when an artist should use the colour red. > > > > Well, I generally disagree. Procedural development using RDBMS is > > fairly strait-forward in many or most shops: Normalize your schemas (to > > reduce info redundancy), > > Except, of course, that it is not that simple. While normalised data > gives better data integrety, it can give longer read times. Are you > able to give "carefully worded individual guidelines" about when to > keep which data normalised? It depends on the kind of reads being done. Normalized is the best way to optimize for the unknown. A common pattern is denormalize copies for special data mining projects. These generally look at weekly or monthly trends, so they don't need to be live. > > > break the problem down into a series of > > relatively-independent tasks/events, > > Right -- and you're able to give "carefully worded individual > guidelines" for how and when to break a problem into sub-tasks? "Stepwise refinement" is fairly well studied and documented. For example, here is a rough task-breakdown of "brush teeth". (Sorry about the funny punctuation.) Brush Teeth .....*.find.toothbrush .....*.find.toothpaste.tube .....*.open.toothpaste.tube ...........o.Put.thumb.and.pointer.finger.on.cap ...........o.turn.fingers.counter-clockwise. .....*.clean.teeth ...........o.put.brush.on.teeth ...........o.move.back.and.fourth.vigorously ...........o.repeat.above.step.100.times. .....*.clean.up ...........o.rinse.brush .................+.turn.on.water .................+.put.head.of.brush.under ...................running.water.for.30.seconds .................+.turn.off.water. ...........o.put.cap.back.on.toothpaste ...........o.put.all.items.back.in.cabinet Most people would produce a fiarly similar hierarchy without even seeing this one. (Some steps are missing I notice, such as "put toothpaste on brush".) Interactive systems tend to have smaller tasks, using the database as the common inter-task communication "chalkboard". > > > and factor common functionality > > into shared libraries or consider developing a declarative framework > > using RDB tables. > > And you're able to give "carefully worded individual guidelines" as to > how to factor out common functionality? No. But repeation factoring is fairly similar across paradigms. Thus, it is not really a paradigm-specific skill to compare on anyhow. > > > I don't always agree > > with them, but speed issues are a side topic to some extent. Moores Law > > will wipe out most of such issues anyhow in 50 or so years (assuming > > comparable "big-O" scores). > > Three things: > > Moore's Law is an observed trait, and not a law of nature; at some > point it will cease to be accurate. But I think we have a long way to go. Parellel processing is just starting to be explored for "use by the masses", for example. But I don't want to get into DB speed issues right now. Another month maybe. (I can give you a wiki link if you want to get into this more.) > > Secondly, Moore's Law that describes the increase in power of the CPU, > and _not_ physical storage mediums, which is the main limiting factor > for database access. The speed of hard-disks reads and writes have > increased far less dramatically over the years. Yes, but on the flip side, more can be cached in RAM. > > Thirdly, the point is moot anyway. Two equivalent systems, one written > with OO methods and the other with procedural ones will have to read > and write the same data to the backend database _anyway_, since > they're supposed to do the same job. Unless one of them has done a > right hatchet-job of the database access or uses the database > needlessly, the speed of the database won't make a whit of a > difference between the two systems. Procedural designs tend to delegate the "noun model" to the database, while OO systems want those models in code. OO code will often have classes that mirror schemas, for example. OO wastes a fair amount of code translating between paradigms instead of using the database to do well what it does well. > > (You have been told this time and time again, so it can't precisely > come as a shock to you; but it is just as easy to use relational > databases in OO development as it is to use them in procedural > development.) No, because OO and RDBMS overlap in many ways. Procedural has more of a Yin-Yang relationship with the DB because it is fine with a declarative data-centric interface to things, while OO wants behavioristic interfaces to stuff. As evidence of this, many OO proponets feel that OODBMS should be perfected because they don't really like RDBMS. But the market has rejected OODBMS. (And, exactly what an OODBMS is, is not well-defined.) > > -- > Leif Roar Moldskred -T- |