Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 10 Jun 2005 11:28 >> 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. > First, you have to understand it... Yes, first *you* have to understand the scientific process and how to present objective evidence rather than only vague salesy brochure-talk. -T-
From: Christer Ericson on 10 Jun 2005 12:40 In article <m2ekbas0l2.fsf(a)gigamonkeys.com>, peter(a)gigamonkeys.com says... > [...] > <http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html> In it you say, "The fundamental idea of object orientation is that a powerful way to organize a program is to define data types and then associate operations with those data types." What you give here is the definition of an _abstract data type_ (ADT), nothing more, nothing less. Functional languages in the ML category, for example, all support ADTs as a way to "define data types and then associate operations with those data types" but we hardly call them object-oriented. The commonly accepted view is that _only_ when we add the feature of enclosing _data_ in the ADT does it become an object. That is, the fundamental idea of object orientation is to combine within an entity (which we call the object) data and operations on that data. -- Christer Ericson http://realtimecollisiondetection.net/
From: Robert C. Martin on 10 Jun 2005 15:20 On 9 Jun 2005 21:22:18 -0700, "topmind" <topmind(a)technologist.com> wrote: > >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. Agreed, and you'll find plenty of examples of systems like that in my articles and books. >I gotta force OO out of its comfort zone >in order to expose it for what it is. You will expose it as a useful technique for managing dependencies. ----- 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: Robert C. Martin on 10 Jun 2005 15:21 On 10 Jun 2005 08:28:44 -0700, "topmind" <topmind(a)technologist.com> wrote: >Yes, first *you* have to understand the scientific process and >how to present objective evidence rather than only vague >salesy brochure-talk. that's a troll response. Prepare to be ignored. ----- 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: Robert C. Martin on 10 Jun 2005 15:58
On 9 Jun 2005 21:46:53 -0700, "topmind" <topmind(a)technologist.com> wrote: >> 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. Yes, there are some of those too. There are LOTS and LOTS of examples. Some are technical, some are business. OO is useful for *all* kinds of software. >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. Interesting. We *didn't* think about keeping and RDBMS as an option. And yet we managed anyhow simply by isolating the storage mechanism behind polymorphic interfaces. >Thus, I considered the idea of a generic wrapper >around the "persistence mechanism" (cough). We needed that wrapper (which amounts to an interface, not a lot of code) just to keep the tests running fast. >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. Interesting, we didn't have to do that. We kept the interface above the level of and RDBM API, and refused to pollute the higher level code with such details. >I gave up the generic idea, tossed the wrappers, and >the code was smaller can cleaner. And bound to the RDBMS. If we had done that, our tests would be too slow, and we would have to ship the system to our users with some kind of RDBMS attached. >Things like *concurrency*, searching, and cross-referencing were made >pretty simple by the RDBMS. Granted. RDBMSs are very powerful. Sequestering that power behind interfaces is what allows a system to be portable and deployable in many different user environment. Such sequestering means that designers have to get creative about how to access the power of the RDBMS from the other side of the interface. >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. I invite you to look at the code. That's not what happened. The interface is quite clean, and does not reinvent an RDB. >You essentientally wrapped away from >RDBMS by almost building a DBMS of your own. Not very good "reuse" if >you ask me. You might want to check your facts before you report them Mr. Isikoff. However, the point is not without some merit. For our purposes it was easy to create a simple file system storage mechanism. However, there are other systems where such segregation would not be worth doing. The fact that OO techniques help you to sequester certain subsystems does not mean that such sequestering is always a good idea. >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. Agreed. On the other hand, it would be a shame to use one when you don't need it. > >A RDBMS *is* an interface, by the way. Think about that long and hard. I have, and I shall again. An RDBMS is indeed an interface. ODBC and JDBC are *polymorphic* interfaces that bind your application to any particular RDBMS you are interested in. So if you are using ODBC or JDBC, you are using OO techniques to talk to your database. If you use COM or ActiveX, you are using OO techniques to talk to your components. ----- 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 |