Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
Prev: Use Case Point Estimation
Next: Association Class
From: Robert C. Martin on 9 Jun 2005 22:49 On Thu, 09 Jun 2005 16:13:48 -0500, Robert C. Martin <unclebob(a)objectmentor.com> wrote: >Or, to get very concrete, OO is a way of structuring programs such >that data structures are manipulated by functions called through jump >tables contained by those data structures. To get even more concrete, OO is the technique of keeping the stack frames of certain functions on the heap; and allowing them to live longer than the functions that called them. (Nowadays we call these special functions Constructors). While this, by itself, is not polymorphic, it's a very simple step to add the jump table to that orphaned stack frame. ----- 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: topmind on 10 Jun 2005 00:22 > Topmind, nobody is going to respond to statements like > this, because everybody is going to assume that you > haven't done your homework and > won't understand the response anyway. What > would be the point? CopoutRedHerring. Science is independent of me. Just produce solid evidence or stick your OO braggin' where the sun ain't shine. In other words, a place as dim and smelly as your evidence. > But if you took one of RCM's papers off his web site, > and prepared a serious critique that demonstrated > both that you understood it and also that > you disagreed with it, RCM would very likely > respond to that. But all his examples are device drivers. I *already* agreed OO is good for device drivers. But so far it is a one-trick pony. Make that two trick: Device drivers and shapes. What about something like an airline reservation system, a student grade tracking system, and inventory system, a finance estimating system, etc. Maybe they are not glamorous or fun, but THAT is the kind of thing that most developers work on. I am sick and tired of device drivers, animals, and shapes. I gotta force OO out of its comfort zone in order to expose it for what it is. -T-
From: topmind on 10 Jun 2005 00:46 > You may investigate this by looking at the source code of this > particular program. You can download it at www.fitnesse.org. I see things like socket examples. Regarding your wiki example, I actually wrote my own wiki about 5 months ago. At first I decided to use files instead of a RDBMS for the hell of it. But, I wanted to keep open the possibility of later switching to a RDBMS. Thus, I considered the idea of a generic wrapper around the "persistence mechanism" (cough). But then I realized I had to make it rather low level to deal with a lot of crud that RDMBS take care of for me. I gave up the generic idea, tossed the wrappers, and the code was smaller can cleaner. Things like *concurrency*, searching, and cross-referencing were made pretty simple by the RDBMS. A generic interface that can handle 3 of files, RDBMS, and RAM is going to be bloated and end up reinventing a database more or less anyhow. You essentientally wrapped away from RDBMS by almost building a DBMS of your own. Not very good "reuse" if you ask me. RDBMS are more than just a "persistence mechanism". They are "attribute managers", and if you know how to use them properly, they handle a lot of grunt-work for you. A RDBMS *is* an interface, by the way. Think about that long and hard. -T- oop.ismad.com
From: Rob Thorpe on 10 Jun 2005 04:18 Phlip wrote: > Rob Thorpe wrote: > > > What you've written above gives a basis for understanding the problem. > > But you've missed an important part, to have an object-orientated > > program you need data and subroutines connected together in some entity > > called an "object" or "class" depending on the terminology. > > "I can identify Encapsulation and Inheritance as aspects of the 'leverage' > term in my definition. They help make fOO integral to a system." My point is, it is not necessary to have polymorphism, inheritance or jump tables to bind code and data into an object. All that is necessary is that the two things are presented together. > > > By your definition this program is not fOO, I would agree with that. > > However, by the normal textbook definition of object-orientation this > > program is OO. > > OO programs (and fOO programs!!) enable the Liskov Substitution Principle. What does the Liskov substitution principle have to do with anything? A program like that I describe could fulfill the Liskov substitution principle, or it could break it, it's beside the point. Of course with a complex enough pattern of inheritance and complex enough object behaviour it becomes hard to obey it (or indeed do much useful) without polymorphism. > But, agreed, some textbooks are lame. The textbooks I refer to certainly aren't lame since they use the normally accepted defintion of OO - ie. that written in most books and used by most programmers. I have never read a book that ties OO to polymorphism as you have tried to, but I would be interested to know if such a misleading text exists. > > The books I have read and the programmers I have known in the past have > > always used OO in the way I do above, not tying it to polymorphism. > > Maybe terminology is simply different in the field you work in, > > terminology in OO tends to be confused, but it is different from common > > usage. > > My field is The Church of the SubGenius. I am a disciple of Bob. ;-) Ah, that explains a lot. Personally, I worship at the church of the four X's (at least when in Australia).
From: Dmitry A. Kazakov on 10 Jun 2005 04:44
On Thu, 09 Jun 2005 16:13:48 -0500, Robert C. Martin wrote: > I don't think so. Polymorphism is the ability for an object to > respond to a message in a manner that is consistent with it's type. Isn't it rather strong typing? The definition "one interface, many implementations" is IMO more consistent, though admittedly vague. What you describe is rather a "strong typed" reaction to polymorphism (of objects and methods), i.e. dispatch. > Or, to get very concrete, OO is a way of structuring programs such > that data structures are manipulated by functions called through jump > tables contained by those data structures. Ooch. Can a goal of software design/structuring/etc be "calling functions through jump tables"? You belittle OO! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |