begin quoting David Brown as of Sat, Mar 22, 2008 at 12:33:15AM -0700: > On Sat, Mar 22, 2008 at 12:22:55AM -0700, [EMAIL PROTECTED] wrote: > > >IMHO the essense of OOP is organizing related functions and data into > >distinct units. We call these data-function blobs "objects". > > Actually, that almost entirely misses the point of OOP. I would call that > more something like modular programming or structured programming. Um, no, that's the key and the crux.
Yes, it's very like modular or structured programming. The difference is that (in OOP) if my code is handed a data structure, the behavior is available... I don't have to find the function that knows how to handle THAT data structure. It's there "in the object". (Implementation details will vary, naturally.) > There are several aspects that are important to OOP, all of which can be > done independently, but people tend to bundle them together and call it > OOP: Mostly people list their favorite language features, regardless if whether or not it is necessary. > - organization, as you have mentioned. The *essential* one, I argue. > - data or structure inheritance. Allowing subtypes that contain the > fields of parent types with possible additional fields added. And then there are languages like Self that don't have classes, and thus no "inheritance"... > - Dynamic dispatch. Probably the most important part. Allows calls to > be generalized C++ uses static dispatch by default, doesn't it? If you write a C++ program and never define a virtual function, is your code necessarily not OO then? I'm trying to think of an OO language that doesn't have *any* dynamic dispatch, and failing, so I think you're right (and I also think this falls out of "data + behavior"). "Features of many OO languages" != "Features of OOP". > >I'm not sure calling it "message oriented programming" emphasizes > >this idea of data-function blobs. > > Why is why some consider it a better term. The emphases is on what is done > not on the blobs of data. A properly organized class system (at least > according to this methodology) won't be though of as a bunch of data, but > as a bunch of abstract entities (objects) that can be sent messages. > > There is a complete equivalence between message passing and generic > procedure dispatch (at least of the first argument). Generic procedures > that dispatch on the types of multiple arguments are more general than > message passing, although there will always be ways of doing the same > thing. It all comes down to assembly/machine code in the end. There's always a way. :) > It can be argued that languages that focus on the fields of classes > distract away from the methods. Ya. -- Keep your data private and your methods public. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
