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).
This pretty much fits what I understand - and does not fit the Alan
Kay
notion (which is more like a process). Where the OO stuff makes
sense is
in clear analogies --- for instance, mathematical types (which can be
generalized to more than the bit size of the processor, or even
unlimited
bit size - or oddball bit size - and still naturally have "methods"
such
as addition and multiplication that exhibit clear analogy in their
behavior, e.g. overflow). But even that can get into trouble (dividing
matrices?). And the key to the mathematical objects is they have a
very
well defined usage of resources (i.e. just CPU and memory, and if done
carefully, limited scratch such as stack). And the subtypes (which are
super-structures, i.e. structures containing more than the parent type
structures) become dangerous when STRICT analogy is not maintained.
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).
I think OO and processes are actually orthogonal, with OO (as you
defined
it) being a technique for organizing (abstract) data assemblages, and
processes (or Kay's objects) being a way of organizing (concrete)
resources. Unfortunately OO is made to expand to include state
machines
(open, read, malloc, etc). Then inheritance becomes metaphoric and
not
analogical (hidden side effects, differences in behavior,
dependencies).
OO (or any other data organization technique) should be a layer on
top of
the process harness. That has always been my design attack: get the
data
flow working with completely unrestrictive "null" algorithms or
methods
(doing nothing except, possibly, forcing delays equivalent to the real
task); then, once that is robust, do the (comparatively easy) task of
adding the real computing.
Larry Dickson