Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 21 Jun 2005 18:06 > > > > 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. > > > 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? > > > 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. You asked for *specifics*. > > > 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. And, here are also some library/publication designs. Although some of the design options described were not actually implemented (to keep the system on-budget), they were considered: http://www.geocities.com/tablizer/lib.htm -T-
From: Leif Roar Moldskred on 22 Jun 2005 02:52 "topmind" <topmind(a)technologist.com> writes: > Do you deny that Java API's sometimes follow that pattern? Does OO design and implementation sometimes lead to bad design and bad code? Of course. Is that a weakness of OO? No; it just means that OO doesn't _guarantee_ good design; just as no other programming model guarantees good design. I haven't found this issue to be a problem with any of the Java APIs I've used or written. You might notice that the article you linked to explains a way to avoid the issue; so for you to use it to support the contention that there is something inherently wrong with OO falls flat. (And if plain old attributes seem too "un-OOish" for your tastes, even though they're not, you can solve the issue by using wrapper classes as well.) -- Leif Roar Moldskred
From: topmind on 22 Jun 2005 11:44 > > Do you deny that Java API's sometimes follow that pattern? > > Does OO design and implementation sometimes lead to bad design and bad > code? Of course. > > Is that a weakness of OO? No; it just means that OO doesn't > _guarantee_ good design; just as no other programming model guarantees > good design. > > I haven't found this issue to be a problem with any of the Java APIs > I've used or written. > > You might notice that the article you linked to explains a way to > avoid the issue; so for you to use it to support the contention that > there is something inherently wrong with OO falls flat. (And if plain > old attributes seem too "un-OOish" for your tastes, even though > they're not, you can solve the issue by using wrapper classes as well.) 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. For example, I cannot tell if R. Martin suggests always using polymorphism for variations on a theme. If not always, then when not? I am not getting specifics on how decisions are being arrived at. That is why I keep focusing on change impact and probability estimation analysis: nobody has proposed a usable alternative. The "coupling" angle is not fleshed out well enough yet. > > -- > Leif Roar Moldskred -T-
From: Leif Roar Moldskred on 22 Jun 2005 12:17 "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. -- Leif Roar Moldskred
From: topmind on 22 Jun 2005 17:11
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), break the problem down into a series of relatively-independent tasks/events, and factor common functionality into shared libraries or consider developing a declarative framework using RDB tables. I agree that there is variation between such designs, but the general approach is the same and the similarities will be remarkable. It is when people deviate from this well-tested model are most messes created IMO. Well, lack of factoring commonality is also a common source of headaches, but that is the same for anything. There is often disagreement over the "factoring threashold", such as whether to wait until something repeats 3 times or 8 times before refactoring to shared libraries/utilities. But at least it is a "known parameter of difference". Some shops like a low level and some a high one. There are also battles over which kind of UI frameworks to use; this can also be a large source of difference. But I think this is mostly because the web-based UI scene is still immature. I've asked for specific instances of flaws in this model from OO proponents, and have yet to see any decent complaints. Often the complaints turn out to be language-specific, especially C limitations or irritations. C is NOT the pinnicle of procedural. Some will also say, "databases are too slow for such and such". 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). > > -- > Leif Roar Moldskred -T- |