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 386|DOS-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.