Hi Larry,One of the better descriptions of objects and classes I've seen comes from Bertrand Meyer. He describes classes as "abstract data types equipped with a (possibly partial) implementation". An object is a run-time instance of a given class. So, while you are correct that an object is in most cases basically a data structure and some associated procedures, that rather misses the point. The key aspect of objects is that they are not just arbitrary data structures with arbitrary procedures, but instances of a type (the class) with a prescribed interface. The OO approach involves designing software that is (ideally) implemented as a collection of interacting ADT implementations. Although it's certainly possible to implement abstract data types in non-OO languages, an OO language provides facilities for controlling encapsulation, treating implemented ADTs as modules, treating ADTs as types within the type system, safely constructing and manipulating ADT instances to preserve invariants, and for defining certain ADTs to be subtypes of other ADTs via inheritance (which in turn allows objects that are instances of the subtype to be treated as instances of the supertype when appropriate, and to do so in a type-checked manner).
I don't particularly want to get into all of the arguments for the use of an OO approach. I think that Bertrand Meyer presents a good case for developing software based on classes and objects in his text "Object-Oriented Software Construction", and I encourage you to dig up a copy of that book if you want to get a better idea of what all of the fuss surrounding OO is about. Note, however, that what Meyer describes is how things *should* be done in OO development, not necessarily how what passes for OO development in many organizations is actually done. It's probably also worth noting that many of Meyer's arguments are probably equally applicable to a process- oriented design approach, and that the approach to OO concurrency advocated by Meyer is explicitly influenced by CSP (both CSP and occam get several mentions in his book).
By way of a disclaimer: I am not an OO zealot. I think OO is a useful model, and that there are uses for it. But I don't think it's the magical cure for all ills that it's sometimes touted as, and I don't think it's always the right tool for the job - I prefer to choose the computational model that best suits whatever problem I'm trying to solve.
Cheers, Allan On Nov 13, 2007, at 8:31 AM, tjoccam@xxxxxxxxxxx wrote:
He said that "Simula said that data-structures and procedures are badideas". This was fantastic! he said. One wanted objects which themselves knew what to do. The basic idea of OOP is "wrap it up and make an API outof it".Hi Oyvind,Correct me if I'm wrong, but isn't an object a data structure in disguise, and a method a procedure call in disguise? And isn't an API a procedure library? I don't know Simula, but all the OO stuff I have ever seen just seems to be data structures and related procedure/function libraries, plus long lists of restrictions on their use and relatedness trees among thestructures based on shaky metaphor. Larry Dickson