larry@JPL-VLSI.ARPA (12/17/86)
Eileen,
I at least read the first chapter of most Ada books that come out and I
still recommend Grady Booch's Software Engineering with Ada for most
beginners. Note that Booch just came out with a third edition. I'm also
impressed with Putnam Texel's book.
For Pascal experts Habermann & Perry's Ada for Experienced Programmers is
good, with many examples all worked out both in Pascal and then in Ada.
Narain Gehani and Norm Cohen each have a book that is a bit more advanced
than Booch or Texel. J.G.P.Barnes text jumps right into nitty-gritty, which
some people like who disdain "all that software engineering propaganda."
But don't take anyone else's word for the one (or more) book(s) you need.
Skim the first chapter, look at the table of contents, and read the
introduction, then pick the clearest one.
************************
One element of Booch's book may not be clear: object-oriented programming.
I assume this because at conferences and in various Ada articles at least
half of the people who sling the term around don't seem to know what it is,
and most of the others are too close to details of how OOP is done to
see the overall picture, the commonalities shared by Ada, SmallTalk, LisP
Flavors, and so on. I hope the following clears this up (and maybe
stimulates some discussion on this list).
An object in a programming language is an analog of some external object.
The most important characteristic of both is a boundary of some kind. The
important dimensions of the boundary depends on what problem you want the
computer to solve. An engineer designing computer circuitry might be
interested in digital pulses, with two crucial dimensions, time and voltage,
which form the beginning, end, "top," and "bottom" of each pulse.
Many objects have not only boundaries but a skin at the boundary. This
protects the interior from the exterior, and vice versa. The more advanced
programming languages also have these skins: in Ada each compilation unit
has a specification which serves this purpose. (The unit with the
"strongest" skin is the package.) There is also typically some control over
the "permeability" and "transparency" of the skins: in Ada private types,
the Shared Pragma, and a few other features perform these functions.
Another aspect of objects is that they fall into classes which have the same
attributes and capabilities. This is useful if you can create subclasses of
objects that inherit attributes/capabilities from the superclass; this saves
the programmer from duplicating the effort of specifying what is inherited.
In Ada derived types, generics, and (in one sense) overloading are
inheritance mechanisms.
Other languages provide additional or alternate mechanisms to support
object-oriented programming. Whatever the language, each mechanism always
has advantages and costs. The software engineer makes trade-offs to produce
an optimum system. For instance, SmallTalk is more useful than Ada for
producing and modifying prototypes; Ada produces much more efficient code.
Object-oriented programming is really an attitude rather than a collection
of mechanisms; it can be used in relatively primitive languages such as
ForTran or Assembler. OOP focuses the programmer's mind on the enduring
components of the desired system, which tends to produce programs that need
little change or can be easily changed.
It also promotes designs that use elements from the problem area; that is,
the programmer tends to think in terms of spaceships and thrusters rather
than data structures and subprograms, or invoices and sales, etc. This
takes advantage of the knowledge and intuitions the programmer has from (or
so we hope!) knowing the problem area. It also tends to reduce the sort of
"painted into a corner" errors that come about when programmers jump into
coding without thinking through all the requirements of the system they're
developing.
OOP is sometimes thought of as antagonistic to older ways of designing
systems. My feeling is that it is more of a superset of previous
approaches. Functional decomposition focuses on the activities of a desired
system, data-structure approaches focus on static data relations, data-flow
combines the two with an emphasis on activities and with a more
implementation-oriented mindset.
As with any tool, there are limits and problems with OOP--something which
no-one I know in the Ada community has addressed. I have to admit I haven't
done much along those lines myself. It does seem to me that there are
probably problem domains in which OOP would have problems, say areas where
objects with boundaries don't exist. And there may be problems that could
better be solved by a more mathematical or symbolic-logic approach.
Larry @ jpl-vlsi.arpa