Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
Prev: Use Case Point Estimation
Next: Association Class
From: Rob Thorpe on 9 Jun 2005 17:45 Phlip wrote: > Gerry Quinn wrote: > > > > Or do you still claim OO is not about polymorphism? > > > > Yes. > > Then I pick a new word, fOO. The definition of "fOO" is "a style of > programming that leverages jump-tables, or their equivalents, to bind > behaviors to messages at runtime." > > With this word fOO, I can identify BASIC as "not fOO". VB Classic is "almost > fOO", and VB.NET is "fOO". > > I can identify a program written in Smalltalk that stuffs all its statements > into one big unstructured method as "not fOO", and I can identify a program > written in C that uses pointers to functions stored in structures as "fOO". > > I can identify Encapsulation and Inheritance as aspects of the "leverage" > term in my definition. They help make fOO integral to a system. > > My word fOO is easy to apply, because it's narrow. Find the jump-table, or > equivalent, and we got fOO. > > My word fOO is distinct, meaning any two engineers can agree independently > whether a system has my fOO. > > The easy and distinct properties together lead to a third property. Because > fOO relates to very important programming topics, and because two engineers > who know my definition of fOO can say "fOO" to each other all day and know > what each other mean, that makes my definition useful. > > Definitions should be easy to apply, distinct, and useful. > > In terms of "correct", what is the difference between my word "fOO" and this > "OO" word you use? Not responding for Gerry Quinn, here's how I see it: 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. Let us say I have a program that has data and routines(methods) collected together into classes. The program operates entirely by objects of these classes interacting with each other through methods. However, there are no virtual method anywhere (and there are possibly no jump-tables since the compiler may take them out). There may also possibly be no inheritance. 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. Significant programs like that I describe above really exist, so the issue is a real one. 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.
From: Daniel Parker on 9 Jun 2005 18:57 topmind wrote: > RCM wrote > > > examples in my book > > My website and examples are provided for free, Oddly enough, so are RCM's. But what about your published books? Are they free too? > > > which is a web server, > > wiki, and acceptance testing tool. > > Okay, how about wiki's. How does specificly does polymorphism improve > wiki's beyond what a procedural version can do? > 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? 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. Regards, Daniel Parker
From: Wavemaker on 9 Jun 2005 19:19 "topmind" wrote: >> The bottom line for OO is that it is a technique for >> managing dependencies and reducing coupling; and >> the primary tool for achieving that is polymorphism. > > And I invite you to demostrate that with code examples > outside of "device driver" examples. (Unless you can > argue that most software issues can be effectively > modeled as or like device drivers.) I'm currently rewriting the playback engine of my MIDI toolkit. I'm designing it so that the timing scheme that drives playback can be switched out. A MIDI sequence can be driven by an internal tick generator, MIDI system realtime clock messages, or SMPTE/MTC. My approach will be to have an ITickGenerator interface that has a "Tick" event that occurs when the tick interval has elapsed. Implementing classes will be a TickGenerator class that provides basic internal timing, a SmpteTickGenerator class for MIDI time code functionality, a SlaveTickGenerator for system realtime messages, and a few other flavors. The key is that each class will implement the Tick event. The playback engine can be handed an instance of any one of the tick generator classes. It registers with the Tick event and uses it to drive the playback. The timing scheme is thus decoupled from the playback engine in that the playback engine doesn't care which scheme is used. Is this equivalent to a "device driver" example? Maybe. Maybe any example of polymorphism will look like the device driver example. But this is a real world problem that I'm solving through polymorphism.
From: Phlip on 9 Jun 2005 19:49 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." > 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. But, agreed, some textbooks are lame. > 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. ;-) -- Phlip http://www.c2.com/cgi/wiki?ZeekLand
From: Robert C. Martin on 9 Jun 2005 22:41
On 9 Jun 2005 14:41:42 -0700, "topmind" <topmind(a)technologist.com> wrote: >> Not even one. Can anybody find a device driver in my website >> articles? I don't write device drivers. > >You used to have a modem driver and lamp controller example >if I remember correctly. It seems they were removed because they >didn't contain the Fad DeJour methodology in them. Nothing has been removed from the Object Mentor website. You remember correctly about the Modem and Lamp controller examples. They've been part of my introductory examples for a long time. They are not device drivers, they are examples. If you turn the page you'll find many others that are much deeper and business oriented. > >> examples in my book > >My website and examples are provided for free, I espect the same >curtesy from you. My website articles are also provided for free. And many chapters of my books are included. You may wish to read through the reprints of my Craftsman column. It shows several simple examples, and some much more involved (10 or more columns) examples related to business projects. All the craftsman articles are on the website. See: http://tinyurl.com/ddrfx > >> which is a web server, >> wiki, and acceptance testing tool. > >Okay, how about wiki's. How does specificly does polymorphism improve >wiki's beyond what a procedural version can do? You may investigate this by looking at the source code of this particular program. You can download it at www.fitnesse.org. Here's a quick story that might give you an idea. We built fitnesse one test case at a time. Test cases were written first, and then the tests were made to pass. In the early days, we were interested in the widgets of the wiki. Things like ''italic'' and '''bold''' being rendered correctly. So we got that stuff to work by creating page objects that were kept in RAM rather than on disk. The name of this class was WikiPage. Later we needed to save the wiki pages on disk. The simplest way to do this was to simply write them to flat files. However, we had hundreds of tests at this point and we didn't want to slow all those tests down by making them all suddenly use the disk. So we broke the WikiPage up into three parts. WikiPage knew how to process the widgets. InMemoryPage inherited from WikiPage and added the ability to save the page data in RAM. FileSystemPage also inherited from WikiPage and provided the ability to save the page in the file system. This was a simple polymorphic separation. Most of the code in the application simply used WikiPage and did not know whether the pages were InMemoryPage or FileSystemPage instances. We could run our tests in RAM, but run the application on the file system. FitNesse grew to be a large-ish application over about a year. 20,000+ lines of Java. *Then* one of our clients decided that they wanted all the pages stored in a MySql Database. This client used the polymorphic structure we had already created, and wrote a DatabasePage class that inherited from WikiPage. This effort took him about a day. In one day he had migrated the storage mechanism of Fitnesse to a relational database. No muss, no fuss. Works like a champ. And it's so decoupled from the main body of code that we distribute it today as a simple plug-in. That's just *one* way in which polymorphism has helped us manage this wiki code. There are 10,000,000 stories of polymorphism in naked business software. You've just heard one of them. ----- 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 |