Slashdot Mirror

I have to be honest. I have not read the entirety of "Object Oriented Software Construction / 2nd Edition," although I did read most of it. The enormity of this thirteen hundred page behemoth is my official excuse. But first, a short introduction for the book and a good deal of why you, and myself as well, should read this book, cover-to-cover.

Object Oriented Software Construction / 2nd Edition, often acronymized by its fans to OOSC2E, was written by Dr. Bertrand Meyer, which is the designer of the Eiffel programming language, and head of Interactive Software Engineering, whose primary product is an Eiffel integrated development environment which they call Eiffel Bench. They have recently released a Linux port of their latest version of this product.

Now for the important stuff. OOSC2E is a must-read book for anyone who takes their programming seriously. This, however, might not be automatically gleaned out of its name. Object-orientation has generated as much mistrust and disbelief as it did praise and following. Take the hackers' development community and try to relate the object-oriented development model to it. Chances are you'd instinctively disregard this option as impractical, and there would be quite much to support this notion. For instance, the hacker's attitude of "everyone's code is everyone's code" seems to stand in opposition to the Object Oriented model's principle of "hide everything but that which should be absolutely necessarily exposed", but that may be a simple misinterpretation of this directive. The hiding principle's aim is not to support the anti-GNU notion of private code, but rather to help avoid misuse of code. I have no idea whether a true object-oriented development model would work for a disorganized group of hackers, but after reading the better half of OOSC2E, I'm not at all sure it's not worth a try. Furthermore, I am utterly convinced that the object-oriented method would yield numerous benefits in any software project large enough, if it were correctly implemented. But enough about Object Orientation. On with the book.

One thing that sets OOSC2E apart from other books that discuss the same subject is the non-condescending, all-telling manner of Dr. Meyer's writing. While many other books which deal with Object-Orientation hit you on the head with dry methodologies and principles, with little or not attempt to explain why you should even bother putting in the extra effort to correctly implement Object-Orientation, OOSC2E is written for the skeptic; for those of us who heard a bit too much about it and are beginning to suspect it to be a red herring. A conspiracy brought upon the heads of die-hard coders to diminish their belief in their abilities. Dr. Meyer does a brilliant job of stressing the importance of the Object Oriented method. First he begins with describing which areas in software development most direly need improvement at the moment, which he does by example, he then goes on to present feasible and reasonable solutions for the problems presented at their simplest and most abstract form. Then he goes on to define a set of more specific rules, from which he derives a set of principles. Thus endeth the book's introduction. By the time you traverse this part of the book (which is rather massive, actually), you're almost guaranteed to have acquired a better understanding of why and how the software development process should be improved.

Starting with the second part of the book, Dr. Meyer takes the reader through the process of implementing the principles that concluded the first part of the book. He does this by developing a rather simple, coherent notation which would allow the reader to better understand the ideas presented in the book. Little by little the notation is developed. Add a language construct here; insert a rule there. By the end of the book you have something which might as well be a programming language, although many programmers would consider it to be too simplistic to be of any use. There's also a dirty little secret concerning the notation which is kept from the reader until the very last page of the book, but most readers would catch on to it very quickly, if not while reading this review. If you'd rather find out for yourself then skip on to the next paragraph, as this may be considered a spoiler. As the book ends, the reader is told that the notation that was so meticulously developed as the book progressed is in fact Eiffel. Many would consider this a shameless commercial plug, since Dr. Meyer's company, as noted earlier, sells an Eiffel development environment. This would also explain why he chose to keep this a secret from the reader until the very last page of the book. Many would resent buying a book that claims to teach the Object-Oriented method, then discover that a good part of it teaches you Eiffel. But Morality aside, spreading Eiffel thin all through the book does nothing to harm its effectiveness. It may be argued that it's a big plus, because by the time you reach the last page, not only have you gained a better understanding of the programming practice as a whole, you've also learned another programming. Fact is that Eiffel is simple enough to aid the learning process rather than hamper it.

Luckily enough, the good writing that characterizes the first part of the book also carries over to the rest of it. But clarity of presentation alone does not make a book the classic that OOSC2E is. The book is virtually paved with mind-blowing and intellectually exciting ideas and concepts. So much that you'll often find yourself smacking your forehead and wonder why certain things have been, and still are, done so differently. Every page oozes uncompromising perfectionism. Ironically, that is exactly why some readers would find this book exasperating at times. One should understand that Dr. Meyer's point of view on the Object Oriented method is just that -- a point of view. There are many other conflicting views expressed by people no less creditable. And whenever the book comes to a debated or debatable point the reader often has to deal with a dogmatic, rather fanatic rationalization of the author's opinions. It is important to remember as one reads the book, not to take everything written as gospel. Dr. Meyer makes many, many excellent points and makes perfect sense most of the time. Just beware of the times he doesn't.

Another group of readers that may find this book exasperating is that composed of programmers of non-Eiffel, Object-Oriented languages, for the same perfectionism discussed in the previous paragraph. The book is filled with many examples taken from other programming, such as C++, Java and Ada, usually under the rubric of "how not to do things correctly". For instance, while it's true that automatic garbage collection is a very powerful programming aid, saying that its absence is unthinkable (C++ implementations, for example, almost never feature automatic garbage collection) may irritate programmers of languages which do not answer to Dr. Meyer's strict criteria, which have, in many cases, proved their usefulness as object-oriented programming tools.

A final note: A thorough read of this book may send you on the search for a good Eiffel tool. As mentioned earlier, ISE does sell a Linux version of their Eiffel Bench, but since I know many of you guys feel religious about the GNU license and since the Linux version is still rather unstable due to it being rather new, you might fancy an alternative. I can recommend two: SmallEiffel, which is a GNU-licensed Eiffel compiler, and Sather, which is a different language based on Eiffel. Sather, mind you, was originally conceived as a free product, which means that everything Sather is freely downloadable, including the language standard, the programmer's manual, tons of additional documentation, a compiler (which works just fine on Linux as far as I can tell), an Emacs major-mode and lots and lots more. It's quite a gem, really. Grab it over here.