Rating: 
Summary: A great book for open minds
Review: Some of the previous reviews have lamented the fact that the book is Eiffel oriented instead of focusing on C++ or Java (or Python, or ...). It is important to remember that Eiffel was developed to support the method, and not the other way around. Meyer didn't set out to write a book about how to do O-O using a particular implementation language (many of which had O-O tacked on), but to write a book about how to do O-O (not withstanding language limitations). Indeed, some of the ideas expressed in the book aren't even currently supported in Eiffel (and in most of those cases, in any language yet).Eiffel was developed to support the method, and the fact that it happens to also be compilable is a bonus. It also addresses some very practical concerns, such as software should be self-documenting (humans/programmers don't like to document, or it will diverge from reality over time). Javadoc comments are a similar idea. I went into this book initially as a strong java/c++ advocate, and was also dismayed that the book didn't center around these languages. But, I had my eyes opened (even though I thought they were already open at the time), and realized that java/C++ (et al.) just weren't up to the task. Design-by-contract is an idea who all by itself is worth it, and many other languages would do well to seriously consider the idea. Also, some people have complained that Meyer is very opinionated and one-sided. This may be somewhat true, however he does not ask you to take any of it on faith. He meticulously justifies everything (there's a reason the book is 1200+ pages), including frequently presenting the arguments in the other direction. You may not agree with everything, but you can't say that he ever gave "because I said so" as the reason. And, at least in my case, if you actually give them serious consideration, even the most adverse (to your current way of thinking) ideas/arguements start to make sense (garbage collection, for example, is one of these ideas that C++ programmers tend to be particularly against). This book is a serious challenge to the "set in your ways" mindset which *many* programmers/analysts suffer from, and those who can actually transend that stand to benefit greatly from reading it, *even if* they continue to use C++/java or whatever. The ideas are O-O specific, not language specific, though some are more or less easy to implement in various languages. The book contains chapters on how to apply the ideas in various languages. For those who would actually like to give Eiffel a try as well, several compilers for nearly every platform (Linux, BeOS, Windows, PalmOS target, and so on) can be obtained for free or very little cost, from several vendors and the open source community.
Rating: 
Summary: Mostly Muck and Mire
Review: The book begins with a bang and ends with distaste. After reading about the first hundred pages or so, I felt that I uncovered a truly remarkable book about programming. The advice it gave seemed concrete, and it had a promising appeal to make me a better programmer. Unfortunately, the next one thousand pages were not able to meet my expectations. In my opinion, there are three major problems with this book: its style, its consistency, and its goal. First, its style. The book is overflated. Meyers often spends several paragraphs describing a concept that deserves a mere sentence. A good editor could have compressed this book down to 600 pages or less. Moreover, his tone is somewhat conceited. He throws words around like 'n-dimensional space', 'topology', and 'monoid' without using them meaningfully. Is he trying to show off his knowledge? Second, the book is not consistent with itself. Meyers states many principles and chides other languages for violating them. However, he occasionally violates them himself. He justifies them via a sentence such as, "while this may appear to be a direct violation of Principle X, it actually isn't because of [some reason that usely isn't very convincing]..." Sometimes I found his reasons were based on misconceptions and personal opinion rather than fact. Third, Meyers' goal for the book is disreputable. The book advertises itself as a general reference for OOP; instead, it teaches the bare basics of OOP and spends the rest of its time bashing other languages and teaching Eiffel, a language developed by the author. I think that this is unacceptable. Is the book completely horrible? No. It does have a couple nice concepts, such as Design by Contract, Bottom-Up Approach, and implicit definitions of Abstract Data Types. However, these three concepts could have been summarized in 50 pages, not 1,250. For these reasons, I recommend getting another book, unless you want to learn to program in Eiffel.
Rating:
Summary: The best and most complete work in Software Engineering.
Review: The first edition of this book changed my approach to software development back in 1988. This second edition surpasses even that book. It reads like a 'whodunnit', with all ideas meticulously examined and reasoned, and the conclusion clearly presented. The reader is not patronised and nothing is expected to be taken on faith. Whatever your level of exposure to OO and software engineering in general, you will find something in this book, even if only a clear presentation of what you know. A student recently told me that she would not have understood her college course on programming and OO if she hadn't read this book beforehand.
Rating:
Summary: Read it again
Review: The greatest achievement of this book is to show you, the reader, how easy, straightforward and appealing the OO technology is... once you have overcome the natural reaction of thinking it is "obvious". Hence my advice is to read it once, put it aside, and re-read it again. Learning OO efficiently means forgetting what you know (or think you know) about OO and trying to follow the Author's idea, and how his views on software engineering interact. You don't have to agree with the Author right away to learn from him. Of course, not everyone can use Eiffel. But only the concepts matter, not their actual implementation. And if you think this book's leitmotiv is "Look how Eiffel is the purest language that embodies all the necessary concepts" (how convenient!), then recall that Eiffel indeed started as a notation and only evolved towards an implementation after the fundamental concepts were layed down. Therefore, no wonder Eiffel seems a natural fit! The audience for this book is any experienced (5 years or more) software engineer, or software architects, whith an experience in designing complex systems and making them evolve over time. Some technical background is required though, otherwise you may only see things superficially and miss the underlying gems. Remember that OO is not a static technology, so to speak. Its natural support for encapsulation and evolution is what makes it an ideal technology in today's modern software management. Read this book again!
Rating:
Summary: Read it again
Review: The greatest achievement of this book is to show you, the reader, how easy, straightforward and appealing the OO technology is... once you have overcome the natural reaction of thinking it is "obvious". Hence my advice is to read it once, put it aside, and re-read it again. Learning OO efficiently means forgetting what you know (or think you know) about OO and trying to follow the Author's idea, and how his views on software engineering interact. You don't have to agree with the Author right away to learn from him. Of course, not everyone can use Eiffel. But only the concepts matter, not their actual implementation. And if you think this book's leitmotiv is "Look how Eiffel is the purest language that embodies all the necessary concepts" (how convenient!), then recall that Eiffel indeed started as a notation and only evolved towards an implementation after the fundamental concepts were layed down. Therefore, no wonder Eiffel seems a natural fit! The audience for this book is any experienced (5 years or more) software engineer, or software architects, whith an experience in designing complex systems and making them evolve over time. Some technical background is required though, otherwise you may only see things superficially and miss the underlying gems. Remember that OO is not a static technology, so to speak. Its natural support for encapsulation and evolution is what makes it an ideal technology in today's modern software management. Read this book again!
Rating:
Summary: A True Gem
Review: The problem with other books on Object Oriented software is that they present arrays of techniques, which are supposed to sum to the Object Oriented Method, in an often loosely coupled way. This book focuses on the unification of these techniques into a coherent method. During unification, the techniques are often stripped of some of their scope. Only parts are used. This may at first seem somewhat limiting to the developer who likes to be master of technique, but the true mastery of any technique lies in knowing which parts of it to apply under what circumstances. The books helps you "cut through the bull" and get to the essence of the problem. As an example, the author not only introduces Exceptions (which are not OO specific), but also fits them neatly into the OO framework. The basic question "under what circumstances do I apply this technique?" is fully answered by "when the contract is broken", and Exceptions are applied only in this context. Even a master of Exceptions will produce better software by sticking to this guideline. The books is a true gem, read it. It reads like a throughly developed mathematical theory, with clearly developed ideas, and relentlessly pursued goals. It builds your own understanding of the OO method, and anything you will read after this you will inescapably try to reconcile with the foundation laid by this book. If then it does not fit, it is likely not OO.
Rating: 
Summary: Useful, but not perfect
Review: There's certainly a lot of stuff in this book that every software engineer should know - including those writing in non-OO languages, many of the concepts are still applicable, just with a little more work. However, there are some irritations, which I shall focus on as everyone else has stated the good points as well as I can. This will result in this review looking incompatible with the 4-star rating I have given the book. Generally, I agree with everywhere Meyer affirms a concept. However, I find him dismissive of useful tools (notably those he hasn't thought of), often on the basis of incorrect usage or analysis - Use cases would be the prime example of this. Also, contrary to the editorial review, I did find the book lacking in demarcation between general OO concepts, and Eiffel specifics. Several points swap between the two without no attempt at signposting the transition. Finally, some of the claims about Design by Contract are overblown. Bug-free software simply does not exist (over a dozen lines, anyway). Anyone who believes they can implement a system perfectly first-time is dangerously deluded, no matter how good the method of its construction. It is exactly that mistake which caused the Ariane crash, and the claim that Design by Contract would have prevented it is false. The Ariane failure was systematic - they examined the contract for the system which failed, but failed to test it at all. In fact, the mode of failure could well be considered an assertion of contract failing. This exception was not handled due to a conscious design decision. The rocket's resulting destruction was due to belief that the software was infallible. I have found these gripes have made reading the book harder, which is a shame as there is a wealth of invaluable content.
Rating:
Summary: Topnotch all time classic on object orientation, a must read
Review: This book and the one from Meilir Page-Jones are absolutely must reads for the serious object oriented software developer. Meyers book is thick and you will learn during the read a lot of Eiffel. The detour is absolutely worth it.
Rating:
Summary: Once again, the Bible of Object Oriented Programming
Review: This book is a delightful read, as it is elegantly edited, and easy to digest. The author takes you through a tour of developing a "notation", where you see various paths and see clearly what the choices are, and why some paths are better than others. Recommended both for beginners (prepare to read it at least twice) and for industry insiders. It is well worth every penny of the list price.
Rating:
Summary: A very complete book, but some strange choices studied
Review: This book presents an exhaustive overview of the object technology in a style which is easy to read. Unfortunately, the author wastes a lot of time studying wrong choices: this means that you will learn a lot on things that will never be implemented and used by programmers, and less on things that have been implemented in languages such as Java or C++.
| 
