Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
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: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 |