With so many books now available on particular object-oriented programming
languages, it is surprising that there aren't more books available to explain
what object-oriented means. Books on C++ or Smalltalk tell you how to use
these languages to implement a system, but they don't tell you much about
the object-oriented approach to designing that system in the first place.
Those books which have been written on object-oriented design, tend to be
one-sided using Fred Brooks' pronouncements to describe the pitfalls and
tar pits of traditional software development, but without much understanding
of the potential pitfalls that object-oriented design, like any design principle,
is bound to have.
Grady Booch's Object-Oriented Design with Applications isn't like
this. It has a strong sense of the real-world issues involved with adopting
and using the object-oriented paradigm. If you are looking for a magic solution
to the problems of software development, you will probably find this book
irritating. But for a balanced assessment of the pros and cons of object-oriented
software development, this is a fine place to start.
Towards the beginning of the book, Booch says that it is good practice to
write programs "so that they don't care about the physical representation
of data." How many times have we heard this from the advocates of object-oriented
design? How many times can you actually write non-trivial programs that
are in fact agnostic as to the physical representation of data?
Well, unlike more amateurish books on object-oriented software development,
Booch doesn't sweep these issues under the rug. Chapter 7 (entitled "Pragmatics")
is particularly good at describing the potential performance risks of object-oriented
design. For example, Booch plainly states that object-oriented software
rarely has "locality of reference," so that special measures must
be taken for it to behave on systems with paged virtual memory. If we care
about performance (!), we often must care about the physical representation
of data too. And while object-oriented software can actually give better
performance, because, for example, virtual functions eliminate the need
for some explicit type checking, on the other hand it can often result in
code bloat. Thus, Booch points out that sophisticated compilers and linkers
with dead-code elimination are needed to fulfill some of the promise of
object-oriented software development.
Booch also shows a grave concern with "performance" in software
development time. Several passages are devoted to design issues that affect
recompilation: "A change in a single module interface might result
in many hours of recompilation. Obviously, a manager cannot often afford
to allow this" (p. 52). "In the extreme, recompilation costs may
be so high as to inhibit developers from making changes that are reasonable
improvements" (p. 205). Thus, to be practical, object-oriented software
development also cries out for incremental compilers.
Booch discusses the key issue of how an organization makes the transition
to object-oriented software development. One section describes the "dark
side" of start-up costs; Booch makes the reasonable recommendation
that one start using object-oriented design in a low-risk project first.
The book also discusses possible organizational obstacles: "Object-oriented
design makes it possible to use smaller development teams. . . . Unfortunately,
trying to staff a project with fewer people than traditional folklore suggests
are needed may produce resistance. Such an approach jeopardizes the attempts
of some managers to build empires" (p. 208).
While Booch's understanding that every benefit has an associated cost makes
this an excellent introduction to object-oriented software development,
I found the actual discussions of design less useful. There is a big build-up
to the chapter on "Classification": Presented with a problem,
how do you find "where the objects are"? Somewhere Booch makes
the central point that not everything is an object, and that here, as elsewhere,
there is no prescription for turning a problem into a neat bundle of classes
and objects.
But the chapter on "Classification" was disappointing. Booch writes
here that "To the developer in the trenches fighting changing requirements
amidst limited resources and tight schedules, our discussion [of classification
philosophy, such as Wittgenstein on categories!] may seem to be far removed
from the battlefields of reality. Actually, these approaches to classification
have direct application to object-oriented design" (p. 140). Unfortunately,
the connection is never really made, making this chapter the book's one
disappointment.
The entire second half of Object-Oriented Design With Applications
contains five applications in five languages: A home heating system in Smalltalk,
a geometrical optics construction kit in Object Pascal (MacApp), a software
house-bug reporting system in C++ (a good example of a useful, yet low-risk
project for an organization making the transition to object-oriented development
to cut its teeth on), a cryptanalysis program in the Common LISP Object
System (CLOS), and a traffic management system in Ada (Booch is well known
for his work on Ada).
Booch states that object-oriented has emerged as a "unifying theme"
in "diverse segments of the computer sciences." Apparently this
theme can be useful in any area where it is desirable to close the "semantic
gap," and he cites several examples of "object-oriented operating
systems" and even "object-oriented hardware," including the
Intel 432 and its iMAX operating system. On the other hand, the RISC paradigm
in computer architecture asserts that there is nothing intrinsically wrong
with the "semantic gap;" object-oriented hardware indeed sounds
like a bad idea. Still, since I work at a company which produces system
software (Phar Lap, makers of 386DOS-Extender), Booch's book had me wonder
about the possible applicability of the object-oriented paradigm to low-level
software such as ours. Recently, Microsoft has been talking about "object-oriented
operating systems." Frankly, I'm not convinced.
While reading the new book by Grady Booch, I had the pleasure of rereading,
for the third time, Bertrand Meyer's Object-Oriented Software Construction.
This is still the standard work on the topic, and the best explanation of
what all the object-oriented fuss is about.
Meyer's book describes the Eiffel language, so you might think it is useless
if you don't have access to Eiffel. But, by using a programming language
to which the reader probably doesn't have access, Object-Oriented Software
Construction makes you concentrate on design issues, not on the peculiarities
of language syntax.
The opening sentence of the book states that "The principal aim of
software engineering is to help produce quality software." Yet, "quality
in software is best viewed as a tradeoff." Meyer also emphasizes the
importance of software maintenance, stating that it is "the hidden
part, the side of the profession which is not usually highlighted in programming
courses." In fact, an awareness of the importance of maintenance has
been one of the driving forces behind the object-oriented movement.
Much of the book is concerned with issues of writing correct and robust
software, and of dealing with errors, exceptions, failures, and abnormal
conditions. Some of this material appears in "Writing Correct Software
with Eiffel," by Bertrand Meyer. (See either DDJ, December 1989
or DDJ bound volume 14.) A glance at the book's index under the entries
"exception" and "failure" will point you to several
lengthy discussions of these often-neglected issues. The sections "Coping
with Failure" (pp. 144-155) and "Dealing with Abnormal Cases"
(pp. 199-203) are superb.
One of Meyer's key techniques for error handling is the assertion, which
he refers to a way to "include specification elements within the implementations
themselves" (p. 112). Meyer introduces a "class invariants"
notation which is, it seems, far more understandable than notations which
have appeared in books such as Barbara Liskov and John Guttag's Abstraction
and Specification in Program Development.
Meyer devotes an entire chapter to object-oriented memory management. The
chapter begins with the statement "It would be so nice to forget about
memory" (p. 352), but Meyer has no illusions on that score. Meyer shows
the problem with the traditional approaches to memory management, including
what he calls "programmer-controlled deallocation," which turns
the programmer into a bookkeeper. What then characterizes object-oriented
memory management? Obviously some form of "automatic" memory management.
"Unfortunately, reference counting is not a realistic technique"
(p. 365), and garbage collection "is unacceptable for real-time applications"
(p. 366).
The Eiffel approach to storage management is essentially a garbage-collection
coroutine: "Execution of an Eiffel system may be viewed as a cooperative
race between two coroutines: The application, which creates objects as it
goes, and renders some dead; and the collector, which chases after the application,
collects all the dead objects it can find, and makes them available again
to the application" (p. 367).
Throughout, Object-Oriented Software Construction provides insights
into the necessary object-oriented "mindset." This mindset has
a "more neutral attitude toward ordering." "Real systems
have no top" (p. 47). Instead, object-oriented systems have a "shopping
list approach." Always try to pass the buck: "Better later than
sooner, says object-oriented wisdom" (p. 50). Meyer argues that looser
systems will be more robust, extendible, reusable, and maintainable than
current systems: "decentralization is the key to flexible architectures"
(p. 431). The object-oriented approach might be caricatured as nothing more
than "lighten up, dude." Meyer shows how the looser, bottom-up,
topless approach really can result in better quality software.
In short, while Booch's new book is more tempered by knowledge of the costs
and possible downsides of object-oriented software development, Meyer's
classic work is a better introduction to object-oriented thinking. The two
books complement each other well, and are recommended to anyone trying to
understand what it means to be object oriented.