Rating: 
Summary: Good basic overview, a solid title
Review: I received this book from a SAMS kiosk at a trade show and really didnt give it much thought. But I started reading it and found it an amazingly good read. The depth and coverage is just right considering its size, and the author really hits the highlights well.This is a satifingy read, well worth the price. I found my thought process really tuned in after its read and many things were given clear definitions that were a tad muddy to me prior to reading it. good book
Rating: 
Summary: Great Starting Place for Procedural Programmers
Review: I'm a business analyst and minor computer hack. I've got programming experience with procedural languages from 15 years ago, like BASIC, SQL, HTML and VB. But no real OOP experience. I've been trying to learn Java, but wanted a "big picture" view of what OOP is all about, before I got down to syntax. This book is more helpful on those lines than most online tutorials I've seen, plus you can read it in a coffee shop, or at lunch- wherever (try that with a Web tutorial). I found that many experienced developers in our group still did not have a firm knowledge of some of the OOP vernacular and concepts, since most people come at OOP from varying backgrounds. It's good to have a common point of reference, and a 'quick-start guide' to learning these concepts.
Rating:
Summary: Great book explaining OOP
Review: I've read a lot of C++ books and this is by far the one that describes Object Oriented Programming the best. If you have been programming C++ before and not really used the advantage of true OOP this is definetely the book that will change your mind. I was caught in the trap of writing procedual code, a bad habit that I got from Pascal and C. This book explains all OOP concepts in a very clear and easy understandable way. The only downside of the book is that the code in the book is focused on Java and not on C++. However in most examples the author also describes the difference between Java and C++
Rating: 
Summary: Steer clear of this book
Review: If you loved "Attack of the Killer Tomatoes" you'll love this book. If you want to learn about OO technologies pick up some other book (*any* other book). When you read the book it feels like it was written overnight, and neither the author nor the technical editors had time to read the book. The text is full of typos (no spell checker?), and code samples speak for themselves: they are one-liners at best, and if there are more than one line author loses the reader completely.
After a couple of chapters of this torture the next chapter turns into a bad book review, where the author starts referring to other books by their page numbers. Then the book becomes a quick Java tutorial, and then a UML tutorial, and everthing else tutorial without a single complete thought. The publisher (Sams) is good, the title is great, the contents page is good, but replace the author and the text.
Rating:
Summary: Intro to OO Instructors - Adopt this text!
Review: In my opinion, this book belongs right up there with the classic "GoF" Design Patterns book on any software engineers bookshelf - it's just not as well known. I use this book as the text for an introductory OO class I teach at a nearby college. As far as I know, there is no other book out there which really introduces the subject of "Thinking OO"; yet thinking in objects is critical if students & software practitioners are going to understand the advantages of OO languages, design, etc.
The advantage of this book is that it is very well written; the authors have considered their intended audience carefully. Some of my students are new to software, and others have been writing procedural code for 20+ years. The experienced programmers have the hardest time switching paradigms, so when they tell you the book really helped them (finally) understand OO principles, it is noteworthy. Some may be critical of the book because lacks academic rigor; but if your objective is for your students to comprehend & embrace OO, you need to adopt this book for your introductory OO course.
Rating:
Summary: This book clears thoughts about Object Oriented Design
Review: It is an excellent book for a programmer to begin Object Oriented programming. It is even better for a person who has done some amount of Object oriented design, analysis and programming. Overall it is a wonderful book.
Rating:
Summary: Good title, but it doesn't belong to this book
Review: It is so unfortunate to see such a good title on this book. In the first part of it, you get the same 10 page introduction to OOP that you can find in a Visual Basic, Powerbuilder or other language-specific book, except the author doesn't even manage to come up with a meaningful difference between objects and classes or a formal definition of polymorphism. In the second part, (the "advanced" part) there is a well confused cobweb of citations from other books, with abundant repetitions, broken sentences and spelling errors. Please buy "Object-Oriented Design Heuristics", by Arthur J. Riel instead, for the language-independent real thing, or "Object-Oriented Design in Java (Mitchell Waite Signature Series)", by Stephen Gilbert, Bill McCarty, for Java. There is one exception where I see this book coming handy: tomorrow morning you have an interview, you told them that you know OOP, and now you are in trouble. If you need more than that, look for another book.
Rating:
Summary: OO for Nitwits
Review: Save your money and find a free online tutorial. If you eliminated all the repetition, and references to other books, this book would be about the length of a magazine article. This book is completely disorganized. Also, it sprinkles advance OO jargon around, such as "granularity", without explaining it, which is worse than not mentioning it at all. You know the expression, "a little knowledge is a dangerous thing"? Well then you will extremely dangerous after reading this book, because for the price, you will have gotten extremely little knowledge.
Rating:
Summary: Synopsis of other writer's books with no additional analysis
Review: This book does not present ideas in the order you should learn them. I do not like his style. I think all information is presented at the same level, instead of key concepts stressed and expanded upon, and junk filtered out. Some examples of what I mean are: Inheritance is covered in chapter 7 of 9. In describing Interfaces and how they differ from implementation, he chooses a power plant example, and includes a picture of a toaster (requesting object) connected to a socket (interface) to a power plant (implementation) via lightning bolts. He picks up on the same topic one chapter later where the interface to a car is the steering wheel, gas pedal, etc, and the implementation is the catalytic converter, etc. The in its own warning box he states "It must be stressed that the interchangeable engines must be identical in every way - as far as the driver's perceptions go. Replacing a four-cylinder engine with an eight cylinder engine would change the rules just as changing the current from AC to DC would affect the rules in the power plant example." It gets worse. "In this book, we will consider composition and aggregation as the same thing." Multiple Inheritance - presented as a more powerful and challenging aspect of class design. That it happens in the real world - you inherit from your mom and dad. That it solves some problems quite elegantly (none offered), but that the increased complexity outweighs the advantages. What not state the disadvantages - I do not think he knows what they are. Next; Behavioral and Implementation Inheritance: "Java interfaces are a mechanism for behavioral inheritance, whereas abstract classes are used for implementation inheritance. The bottom line is that Java interfaces provide interfaces, but no implementation, whereas abstract classes may provide both interfaces and implementation." Besides being misleading to the point of being false, I find it odd that he would take the time to draw a distinction between abstract classes and interfaces but say that composition and aggregation are the same thing. At any rate, I do not recommend the book. I would suggest either UML Distilled or Design Patterns explained. They both do a better job of presenting the right information in a logical and practical manner.
Rating:
Summary: Synopsis of other writer's books with no additional analysis
Review: This book does not present ideas in the order you should learn them. I do not like his style. I think all information is presented at the same level, instead of key concepts stressed and expanded upon, and junk filtered out. Some examples of what I mean are: Inheritance is covered in chapter 7 of 9. In describing Interfaces and how they differ from implementation, he chooses a power plant example, and includes a picture of a toaster (requesting object) connected to a socket (interface) to a power plant (implementation) via lightning bolts. He picks up on the same topic one chapter later where the interface to a car is the steering wheel, gas pedal, etc, and the implementation is the catalytic converter, etc. The in its own warning box he states "It must be stressed that the interchangeable engines must be identical in every way - as far as the driver's perceptions go. Replacing a four-cylinder engine with an eight cylinder engine would change the rules just as changing the current from AC to DC would affect the rules in the power plant example." It gets worse. "In this book, we will consider composition and aggregation as the same thing." Multiple Inheritance - presented as a more powerful and challenging aspect of class design. That it happens in the real world - you inherit from your mom and dad. That it solves some problems quite elegantly (none offered), but that the increased complexity outweighs the advantages. What not state the disadvantages - I do not think he knows what they are. Next; Behavioral and Implementation Inheritance: "Java interfaces are a mechanism for behavioral inheritance, whereas abstract classes are used for implementation inheritance. The bottom line is that Java interfaces provide interfaces, but no implementation, whereas abstract classes may provide both interfaces and implementation." Besides being misleading to the point of being false, I find it odd that he would take the time to draw a distinction between abstract classes and interfaces but say that composition and aggregation are the same thing. At any rate, I do not recommend the book. I would suggest either UML Distilled or Design Patterns explained. They both do a better job of presenting the right information in a logical and practical manner.
| 
