Re: OOD References

[mss@DARTMOUTH.CSNET]

One should be careful when referring to "Object Oriented Design". There
are two separate design approaches that share that name: abstract data
types (a.k.a., data abstractions, information hiding) and hierarchical
types (a.k.a., classes). The former focuses on the idea that an
object's type should be defined by a name (rather than by a storage
structure) and a set of operations on the objects. One thinks of Ada's
packages (with private types), Modula's modules, Clu's clusters or
Alphard forms in this category (no pun intended). Hierarchical types
allow one to provide a "general" interface which can be refined as
necessary, for example, a graphics-object may be further refined into
rectangles and ovals. One thinks of Smalltalk's classes, Simula-67's
classes, Object Pascal's Objects and Scratchpad-8? (84 I think) as
examples. Note that these are orthogonal concepts. One can have
hierarchies without hiding (e.g., Simula classes without the use of
"hidden" attribute) and hiding without hierarchies (e.g., Ada
packages). Smalltalk has hiding and hierarchies.

In reading the literature, one should be especially careful of
separating concerns of "Object-Oriented" systems. A lot of discussion
about the Smalltalk-80 system implies that its Object-Orientation is
what makes the bit mapped graphics, interactive debugging, automatic
garbage collection, symbolic debugger (a.k.a. browser) and other
development aids available. This is not true. For example, MacPascal
(limited though it is) gives many of the same features w/o any pretense
of "Object Orientation". Historically, the development features just
weren't available elsewhere besides Smalltalk-80, hence there is an
implication that the development features and OOD must be synonymous.
In fact, you can get the same features for an assembler system if you
are willing to "pay" for it.  The LRG was willing to pay, the Mesa
group was willing to pay less, others were not willing to pay at all.

			-Mark Sherman (mss@dartmouth.csnet)