| Object-Oriented Software Construction, Second Edition / Bertrand Meyer | ||||||||||
| Reviewed by Tal Cohen | Monday, 20 April 1998 | |||||||||
For Eiffel programmers, the Bible is Meyer’s Magnum Opus, Object-Oriented Software Construction, Second Edition (called OOSC-2 for short). This might seem strange at first, since “Eiffel”, the programming language at question, doesn’t even appear in the book’s title. In fact, you can read the book’s first 1,000-odd pages, up to and including the Epilogue, and never encounter the word “Eiffel”. It first appears as the last word of the Epilogue, on page 1,162. As the book’s title implies, this isn’t a book about the programming language Eiffel, but rather about software construction using object-oriented methodology. But you can hardly teach programming without presenting source code, and the code has to be presented in some programming language. Meyer uses a simple, readable notation that evolves as object-oriented techniques are discussed. The discussion is so complete that the notation ends up being a robust, usable programming language — Eiffel. As Meyer explains in the preface:
Indeed, the resulting language is what many consider to be the best object-oriented programming language available today. As the notation is slowly developed throughout the book, no decision is made without an explanation, no selection made without an intelligent discussion. Often, the pros and cons of each option are presented. The reader might not agree with every choice made, but at least he is shown why that choice was made, and other options discarded. And unlike other methods that focus on correct software engineering, performance is never ignored. The book is divided into eight parts, containing 36 chapters and five appendices. The first two parts, “The issues” and “The road to object orientation,” are an important part of the book, though I suspect many experienced programmers will skip them or just skim most of the text. They really shouldn’t, because in here Meyer sets the background and many of the whys that lead to proper use of OO methodology. Meyer makes several important observation that many experienced software engineers will agree with. For example, on the issue of external software documentation:
This is easily said, but hard to accomplish. Efforts made throughout the years to achieve the goal of self-documenting software, like Knuth’s Literate Programming style, didn’t catch on. The Java language made a step or two in the right direction, with “documentation comments”. But Meyer’s notation includes a complete, useful, easy to use and tightly integrated self-documentation system that actually makes the code simpler to create and easier to understand, rather than burden the programmer. Eiffel also includes other features that will appeal to serious developers. An important example is the correct use of assertions. C programmers are familiar with the assert() function, and they are always told that a good program should include assertions in abundance. C assertions, however, are at best a nice debugging trick, hardly a complete methodology. Serious assertion in C require the use of external formal specification tools, like Larch or Z. It was empirically proven that using these tools can greatly increase software reliability and dramatically decrease development costs. However, few software houses using C/C++ actually use these tools, mainly because they are external and rather alien to the development process. Eiffel assertions are method preconditions, method postconditions, class invariants, loop variants and invariants, as well as “regular” checks. All these form a partial formal specification embedded in a natural, appealing way into the language. While they do not have the power of dedicated specification languages, they are easy to deploy, the language actively encourages their use, they make the code easier and simpler, and they are an important part of the software’s self-documentation. Plus, they are embedded in the software text, an important benefit. Eiffel’s assertions make it possible to locate faults early, which can greatly reduce the total cost of the development process. The fifth part of the book, “Advanced topics”, deals with object-oriented approaches to concurrency, distributed computing, client-server technologies, object persistence, object-oriented databases, and so on. These issues are sorely lacking in many OO methodology or software engineering books. Even if you do not intend to use Eiffel in your development effort, reading this book can still make you a better programmer. After presenting the OO method using Eiffel, the book goes on to discuss alternatives like C++, Ada 95, Smalltalk and Java, showing how they can be better used with proper OO techniques. It even discusses using object-oriented development methods with non-OO languages, such as C or Ada 83. One minor annoyance is that the book seems as if it isn’t sure about the reader’s programming knowledge. I guess people that are not very experienced will have to read it more than once to fully grasp every issue at hand. At any rate, Meyer recommends reading the book in a non-linear manner. A hyperlinked version of the text is in fact included on the CD that ships with the book. Veteran developers will sometimes find the terminology slightly alien (like calling “deferred” and “effective” classes what most programmer would call “abstract” and “concrete”. The two latter terms are put to a different, more appropriate, use.) Meyer knows how important terminology is and takes great care to explain why each term is used. The book is printed in two colors, for making reading easier. I couldn’t help but be reminded of Michael Ende’s The Neverending Story, the most magical two-colored book. OOSC-2, in its own way, is just as magical.
| ||||||||||
©1997-2022 by Tal Cohen, all rights reserved. [About]
This book is about the object-oriented method for reusing, analyzing, designing, implementing and maintaining software; the language is an important and I hope natural consequence of that method, not an aim in itself.