Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Programmer Dude on 24 Jun 2005 19:08 topmind writes: >> Outstanding, you finally have the opportunity to demonstrate the >> advantages of your preferred programming approach over OO in the >> context of a real application. Robert Martin has already provided a >> link to his implementation -- let's see yours. > > Unfortunately, I don't want to release it public because I want some > security through obscurity. Is your code so bad that publishing it is really a problem? Quite a few others seem to have no such concerns. > I might release snippets though. Well? Come on, time to put your money where your mouth is. :-)
From: Robert C. Martin on 24 Jun 2005 22:31 On 24 Jun 2005 05:49:49 -0700, ggroups(a)bigfoot.com wrote: >Isaac Gouy wrote: > >> Robert C. Martin wrote: > >>> On 20 Jun 2005 02:16:36 -0700, ggroups(a)bigfoot.com 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". > >The definition as I understand it. >Notably, a venerable dictionary that I have gives as an example (of >prevarication) things very akin to Robert Martins' tedious self- >righteous tirade . > > >Anyway, where is Nygaard and Dahls' petri dish that they discovered, or >accidently spilled something into ?? > >For such a petri dish does not appear in their recollections of the >origins of Simula ... See Structured Programming, P. 178-179. It describes the notion of taking the function call stack frame (the block) and moving it to the heap so that it can outlast the function that creates it. ----- 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 26 Jun 2005 05:46 "topmind" <topmind(a)technologist.com> writes: > Okay, I admit that the language "crashing and burning" is perhaps an > exaggerated visual metaphore. In other words, you have yet again wasted other people's time with a claim that you now retract. > But I am unclear as to whether you are complaining that I have not > given enough examples of hierarchies having problems, or I have not > shown *extreme* failures. You have not shown examples from real projects of the problems you claim exist with certain OO techniques. > Why are you trying to put the burden on me anyhow? You are the one coming into a venue that is specifically for the discussion of OO techniques and making assertions that are at odds with the experience of most of the other participants. If you want to be taken seriously, you have the burden of describing the context in which you have encountered your alleged problems and of demonstrating that the problems are inherent in the OO approach, not simply your poor implementation. > It is a rational default to assume that real-world "classifications" > are fairly random until proven otherwise, and NOT tree-shaped until > proven otherwise. That is not correct. In fact, it isn't even incorrect. The last three major projects I've been responsible for have been a clearing and settlement system for a very large bank, integration of finance systems across the operating companies of an aerospace equipment manufacturer, and a service delivery platform for a worldwide telecommunications provider. In none of those projects, nor any of the others I've worked on over the past twenty years, have I attempted to model the "real world". What I have done, quite successfully, is build the necessary abstractions to implement the _behavior_ required by the customer. The use of inheritance, either of implementation or interface, to provide polymorphism has been a valuable tool to implement that behavior. Different financial instruments and types of loans, to take two examples from the clearing and settlement system, have similar lifecycles and capabilities, but different specific behaviors. Telco services (e.g. VOIP, video conferencing, etc.) are even more complex, but still have enough commonality that the overall system benefits from the use of polymorphism. It appears that because your experience is limited to relational databases, you are only capable of viewing OO techniques such as inheritance only as a means for structuring data. You need to think in terms of behavior in order to understand OO better (not that I believe you are at all interested in learning). > > The point is that simple systems can be implemented using > > almost any technology. Certain techniques could still be shown to > > be objectively better for various aspects, but the lack of > > complexity means that few limits will be reached. > > Well I dispute that business applications are inherently "simple". I never suggested that. I said that CRUD and reporting applications such as those you have claimed to work on are simple enough that they don't push the limits of most technologies. If you've worked on something more complex, please provide some details. > > Your experience is simply insufficient to support your position. > > So I've been in this biz more than a dozen years doing nothing but > twiddling my thumbs? The only information I have from you is that you've worked only on CRUD and reporting applications. That certainly explains your demonstrated lack of understanding of OO. 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: topmind on 26 Jun 2005 14:24 > > Okay, I admit that the language "crashing and burning" is perhaps an > > exaggerated visual metaphore. > > In other words, you have yet again wasted other people's time > with a claim that you now retract. If you mistake something that is obviously (to normal humans) nothing more than a colorful metaphore as a formal claim, then you deserve to have your time wasted. > > > But I am unclear as to whether you are complaining that I have not > > given enough examples of hierarchies having problems, or I have not > > shown *extreme* failures. > > You have not shown examples from real projects of the problems > you claim exist with certain OO techniques. The taxonomy problems are *real*. And, in those cases I was talking about taxonomies, not necessarily OO. > > > Why are you trying to put the burden on me anyhow? > > You are the one coming into a venue that is specifically for the > discussion of OO techniques and making assertions that are at odds > with the experience of most of the other participants. Most? Have you taken a survey? An informal OO survey at C2.com did not give polymorphism very high ranks. "Encapsulation" and "better models human thought" scored higher. Many OO fans have told me, "don't use trees/poly if they won't work. OO does not require trees/poly to be OO, so stop complaining about trees and mutually-exclusive category lists." (paraphrased). > If you want to > be taken seriously, you have the burden of describing the context in > which you have encountered your alleged problems and of demonstrating > that the problems are inherent in the OO approach, not simply your > poor implementation. Same for you. > > > It is a rational default to assume that real-world "classifications" > > are fairly random until proven otherwise, and NOT tree-shaped until > > proven otherwise. > > That is not correct. In fact, it isn't even incorrect. The last > three major projects I've been responsible for have been a clearing > and settlement system for a very large bank, integration of finance > systems across the operating companies of an aerospace equipment > manufacturer, and a service delivery platform for a worldwide > telecommunications provider. In none of those projects, nor any of > the others I've worked on over the past twenty years, have I attempted > to model the "real world". What I have done, quite successfully, is > build the necessary abstractions to implement the _behavior_ required > by the customer. > > The use of inheritance, either of implementation or interface, to > provide polymorphism has been a valuable tool to implement that > behavior. Different financial instruments and types of loans, to take > two examples from the clearing and settlement system, have similar > lifecycles and capabilities, but different specific behaviors. Telco > services (e.g. VOIP, video conferencing, etc.) are even more complex, > but still have enough commonality that the overall system benefits > from the use of polymorphism. That appears to be little more than "feature selection" (where a feature can be behavior also). Feature selection can be turned into a declarative form if you know how. Using polymorphism generally assumes a hierarchical taxonomy of such products in order to stay change-friendly. I have found time after time that if you look hard at such "taxonomies", they are usually bogus. Customers really want to mix-and-match specific features rather than bundled deals and the combinations of features are generally not hierarchical. Maybe old-fashioned companies try to bundle features, but the move is toward instant customization. Car manufacturers are moving toward this instead of the "level" lines we are used to. A customer order is sent directly to the factory rather than hope a match has already been made by cooincidence. Upgrade to sets or become the Taxonomy Dinosour. Sets are the future. You can share commonalities with sets also. Polymorphism is one way to share commonalities, but not the only and often not the best. Sets are a better hedge because they can represent trees if changes and organization do fit trees, but can still handle non-tree changes far better than tree-centric approachs such as polymorphism. You haven't presented much evidence that you are not unecessarily hard-wiring taxonomies into code. > > It appears that because your experience is limited to relational > databases, Limited to? RDBMS are behind some of the largest applications around. > you are only capable of viewing OO techniques such as > inheritance only as a means for structuring data. You need to think > in terms of behavior in order to understand OO better (not that I > believe you are at all interested in learning). Like I said above, they are generally interchangable, and a declarative represention of behavior selection is often superior because there are more "maths" available to attribute manipulation and attribute view management than there are for a behavioral version. Maybe someday this will change, but as things stand, a behavorial view is currently less "mathable". > > > > The point is that simple systems can be implemented using > > > almost any technology. Certain techniques could still be shown to > > > be objectively better for various aspects, but the lack of > > > complexity means that few limits will be reached. > > > > Well I dispute that business applications are inherently "simple". > > I never suggested that. I said that CRUD and reporting > applications such as those you have claimed to work on are simple > enough that they don't push the limits of most technologies. If > you've worked on something more complex, please provide some details. I don't understand why you suggest that reporting systems are inherently "less complex" than whatever you have in mind. I have worked on e-commerce, equipment tracking systems, scheduling systems, billing systems, etc. One is *not* inharently more or less complex than the other. It depends on the situation, company, and needs. MIS systems are important to strategic planning, decision-making, and trend monitoring in companies. Billions are leveraged on the information they provide so they often have to be accurate, powerful, timely, and able to present combinations of views based on combinations of factors. You appear naive. > > > > Your experience is simply insufficient to support your position. > > > > So I've been in this biz more than a dozen years doing nothing but > > twiddling my thumbs? > > The only information I have from you is that you've worked only > on CRUD and reporting applications. That certainly explains your > demonstrated lack of understanding of OO. At least you seem to be agreeing that OO may *not* be appropriate for CRUD and reporting applications. That is a start. Thus, beat it and go sell to the alleged high-brow app domains instead, and leave us lower life-forms alone. Just don't forget the disclaimer: WARNING: THE SELF-ELECTED DOMAIN GENERAL PATRICK HAS DETERMINED THAT REPORTING AND CRUD IS TOO LOW-BROW FOR OOP. ONLY USE OOP FOR HIGH-BROW APPPLICATIONS; OTHERWISE YOU MAY BLOW THE BUDGET AND DIE OF CANCER. Finally an admission that OO may suck for some domains. One down, hundreds to go.... > > Sincerely, > > Patrick -T-
From: CBFalconer on 26 Jun 2005 15:06
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > .... snip ... > >> Why are you trying to put the burden on me anyhow? > > You are the one coming into a venue that is specifically for the > discussion of OO techniques and making assertions that are at odds > with the experience of most of the other participants. If you > want to be taken seriously, you have the burden of describing the > context in which you have encountered your alleged problems and of > demonstrating that the problems are inherent in the OO approach, > not simply your poor implementation. Er - comp.programming has not, to my knowledge, ever tried to limit discussions to OO techniques. -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address! |