Rating: 
Summary: Once in a while something profound happens....
Review: ...this is one of those times..I dont want to sound like some sad fan who wants to sing your praises like a dancing school kid, but I received a copy of the latest book on Saturday and was taken aback - although not suprised. [Meyers88] for me was an amazing book, but due to priorities (misdirected at the time) I never pursued the research the book deservered (I didnt get the book in 88, but I had a copy around '92-94).
I think it is true to say, I have purchased many OO books and none of them have really inspired me or gone to the level I need. James Oddell's OO Foundations and also his Advanced OO Principles book have been the only other books that I could compare to the quality and profound insight of [Meyers88]. Other books have been pretty insightyful (the Catalysis book is pretty cool), but none have really been amazing....until this current book.
Like I say, I dont want to spend my time embarassing myself, but I do feel it appropriate to at least to thank Robert Martin for the obvious time and effort in sharing his skill and expertise. I havent been able to put the book down since I got it (I am extremely tired!), and there have been probably no more than a handful of books that have ever done this to me. The book is a masterpiece in my eyes, and can most definitely sit along side [Meyers88] and [Booch].
I am sure Robert Martin will realise all the acclaim this book deserves.
[Meyers88] Object Oriented Software Construction edition 1
[Booch] Object-oriented Analysis and Design with Applications
Rating:
Summary: Required Reading - none better
Review: Absolutely no one writes as well, knows as much, or has as much to say about designing world class programs as Robert Martin. This book should be on every serious programmer's shelf; whatever language you happen to be programming in.
Rating:
Summary: The best OOD book out there...
Review: Agile Software Development is a great Object-Oriented Design book that presents it's subject in the context of Agile Development. The book delivers solid design and programming advice in a very "light" style. Not light in that it avoids technical detail! No, Bob seems to have taken the principles of agile development and applied them to the art of technical book writing. The book is divided into six sections and has four appendices. There are numerous UML diagrams and many code examples in C++ and Java. If you don't know UML two of the appendices will introduce you to it. The book takes a top down approach to presenting the material. You are first given a quick overview of agile development practices. I particularly liked the Testing and A Programming Episode chapters from this section. The second section presents five high-level design priciples that every developer should learn and apply. Case studies dealing with a payroll system, weather station software, and testing software are then presented. Each case study section starts by discussing the design patterns that will be seen in the case study. Section Four discusses subdividing the payroll system into packages. Six principles and a set of package Dependency Management metrics (I've known them as the "Martin Metrics" for years) are covered. The book wraps up with the two UML appendices mentioned above, a comparison of two imaginary developments, and an interesting article by Jack Reeves. In my opinion Agile Software Development Principles, Patterns, and Practices is the best OOD book out there.
Rating:
Summary: The best OOD book out there...
Review: Agile Software Development is a great Object-Oriented Design book that presents it's subject in the context of Agile Development. The book delivers solid design and programming advice in a very "light" style. Not light in that it avoids technical detail! No, Bob seems to have taken the principles of agile development and applied them to the art of technical book writing. The book is divided into six sections and has four appendices. There are numerous UML diagrams and many code examples in C++ and Java. If you don't know UML two of the appendices will introduce you to it. The book takes a top down approach to presenting the material. You are first given a quick overview of agile development practices. I particularly liked the Testing and A Programming Episode chapters from this section. The second section presents five high-level design priciples that every developer should learn and apply. Case studies dealing with a payroll system, weather station software, and testing software are then presented. Each case study section starts by discussing the design patterns that will be seen in the case study. Section Four discusses subdividing the payroll system into packages. Six principles and a set of package Dependency Management metrics (I've known them as the "Martin Metrics" for years) are covered. The book wraps up with the two UML appendices mentioned above, a comparison of two imaginary developments, and an interesting article by Jack Reeves. In my opinion Agile Software Development Principles, Patterns, and Practices is the best OOD book out there.
Rating:
Summary: Extra Credit Bob for mentioning Kuhn twice!
Review: As a developer new to OO programming I have struggled (and still continue to) to wrap my head around the power of objects. How do I construct well designed OO software? How do these design patterns work? And how do I wrap some sort of process
around my development to ensure that I produce the best software I can? One answer is to hire Robert C. Martin but failing that you can get a virtual Uncle Bob in the form this book. Robert has managed to impart so much in one text. John Vlissides describes it best I think (on the back cover) as a
weaving of agile methods, patterns, and principles of modern software development. I particularly liked the sections describing the OO design principles and the use of design patterns. I found the code
examples excellent. It would have been nice to have them ALL in Java but that just meant that I had a few exercises
to do :-) Robert's writing style makes this book very easy to read but it is by no means light in content. Questions that came to
mind as I read were frequently answered as I turned the page. (And if you still have one that is unanswered, you can
always ask Robert via comp.object) In fact anyone who as ever submitted a question to comp.object is probably already familiar with Robert C. Martin and if
you do follow this newsgroup you've just got to read "A Satire of Two Companies" in the appendix section. In summary this book has provided me with so much great stuff on good OO design and the use of patterns that I am
constantly referring to it and will no doubt be re-reading many chapters. I am not sure if there are many "must have books" on the market but this is definitely one of them!
Rating:
Summary: Extra Credit Bob for mentioning Kuhn twice!
Review: As a developer new to OO programming I have struggled (and still continue to) to wrap my head around the power of objects. How do I construct well designed OO software? How do these design patterns work? And how do I wrap some sort of process
around my development to ensure that I produce the best software I can? One answer is to hire Robert C. Martin but failing that you can get a virtual Uncle Bob in the form this book. Robert has managed to impart so much in one text. John Vlissides describes it best I think (on the back cover) as a
weaving of agile methods, patterns, and principles of modern software development. I particularly liked the sections describing the OO design principles and the use of design patterns. I found the code
examples excellent. It would have been nice to have them ALL in Java but that just meant that I had a few exercises
to do :-) Robert's writing style makes this book very easy to read but it is by no means light in content. Questions that came to
mind as I read were frequently answered as I turned the page. (And if you still have one that is unanswered, you can
always ask Robert via comp.object) In fact anyone who as ever submitted a question to comp.object is probably already familiar with Robert C. Martin and if
you do follow this newsgroup you've just got to read "A Satire of Two Companies" in the appendix section. In summary this book has provided me with so much great stuff on good OO design and the use of patterns that I am
constantly referring to it and will no doubt be re-reading many chapters. I am not sure if there are many "must have books" on the market but this is definitely one of them!
Rating:
Summary: This book is a gem!
Review: Dr. Martin has done a wonderful job putting together Agile Software Development Practices, Design Patterns, Metrics and Case Studies! The book is polished. Reader is fed high quality, practical advice from one of the top software engineering gurus. Through numerous examples, case studies and crystal clear language Dr. Martin distills the essential Agile Practices, explains Test-Driven Development, illustrates appropriate use of Design Patterns and explains importance of Structural Metrics. I highly recommend this book; your money and time will be well spend. Alex
Rating:
Summary: A Question When Reading the Book.
Review: First, I will say it is an excellent book, anyone who is looking at the front page and thinking about the payment should not hestitate anymore. Second, I have a question hoping that someone can explaint it to me. When Uncle Bob talk about the LSP(Liskov Principle), he give an example----Line and LineSegment, if you remember that, read on... This example confuse me so much, we use inheritation because the two class contain differences (at least one). If in this situation we cannot use inheritation, what else can we? Recalling the memory of most the codes I have written, the child classes have different behavior when comparing with its father class, in those situataions, I should do the drawing actions? Then in what situation should we use the inheritation? If you have your ideas, please be free to contact me through email, I am dying to share the master's thinking with you!
Rating:
Summary: PPP are excellent, but not the XP
Review: I am not a XPer, and I am not convinced to be one after reading this book. The first section (Agile Development) sketches XP(Extreme Programming). It reads "Everybody works on the GUI. Everybody works on the middleware. Everybody works on the database..." Basically, everybody works on everything. Have a doudt yet? Here is more, "Individuals and interactions over process...Working software over comprehensive documentation". It seems to me that XP team is an elite team, whose members are the industry experts with aboundant design knowledge and experience, they know OO technology deep inside and out. To form such a team is a luxury even if it is affordable. In normal corporate environment, team members are at different level with different specialties, it is more beneficial to the corporate to utilize these specialities, e.g., to ask a GUI person to design database or ask a server-side developer to write GUI would cause unnecessary slow-down (if not disaster) of the project. Generally speaking, relying on individual over process is not a safe play for any companies. People on the team come and go, how do you keep the project going? How do you train the new comer to catch up with the project? Reading code is definitely one way, but a slow way I believe. Without have a big picture of whole application architecture, diving into thousands of lines of codes is intimidating and frustrating. Documentation is one important step in the software develop process. Design document (of course, keeps up with the design/code change) is a good way to start, diagams are far more easier to descibe the functionalities of the application, and its modules, and their interactivities. (A picture is worth a thousand lines of code :)) Some people (software people) compare building softwares with building houses, especially when talking about design patterns. Would you imagine that the builder would build a house without a blueprint (the document)? Would you also imagine every worker will work on everything, architecting, grounding, framing, electric, roofing, dry-wall etc.? People with different specialties work on different areas. One more thing I think it is overemphsized is the refactoring. Refactoring is good price to pay when the original design deteriorated. But it does not mean you don't have to think about design at all when you do it the first time. It is not free, why pay this cost if you can get it right the first time? Without solidate design knowledge and abide by the design principles, refactoring can be hard or even impossible. I do agree on some points presented, e.g., short cycles, test-driven development, continous integration, I see these methodologies applied in practice. I also see the author's points that I don't agree, but I think XPers are streching them, either over-emphsizing or under-emphsizing them. Don't get me wrong. Having said a lot of different views about XP, the book well deserves 5-star for the rest of it. The design principles are invaluable heuristic conclusions from industry experts. It amazed me that how few developer are even familiar with these principles, though they are the essence and root of OO technology. One example, A lot of developers are obsessed with if/elseif checking on the run-time type, and they claim if a new type is to be supported, the "only" thing that is needed is to add a extra elseif. If they know what is OCP (open-close principle), they will never write the code same. For those code lovers, they won't be disappointed. Three full-length case studies with a lot of Java/C++ code are included. If you think "Design Pattens" (by GoF) is dry, these rehashed patterns presented here will be juicy to chew on. One particular point that the other authors seldom touch is the packaging. There are several principles for package dependency management. You would think it is unimportant until deployment time, all those tangled packages' dependency forced you to deploy everything (including both GUI and server) as a bulk jar. And isn't it intuitive to do a top-down package design? Until you find yourself in a awkward situation at the end. You will know why and how to avoid these pitfalls after reading these principles. Lastly, it is fairly interesting that the author even supplies some formula to measure the abstraction, stability of the packages. Avoid the "Zone of pain and zone of useless", keep to the "Main sequence" if you want a painless and stable application.
Rating:
Summary: Get it. Read it. Use it.
Review: I bought this book after attending a conference and meeting Uncle Bob himself. If you ever have the chance to see Bob in living color (and remember to ask him why we see the colors we do) don't pass it up. In order to get the most out of this book you need to be open to his philosophy and have some experience. I say this, because I feel it's only after you can say to yourself "I know exactly what you're talking about", or in my case, "Geez, I'm guilty of that", that you understand the principles Bob is trying to get across and the applicability, or lack there-of, of patterns. Bob does an excellent job of setting up the material and then showing an example (a believable one at that) of how to apply the concepts. For example, he will introduce a set of patterns and then provide a case study that applies those patterns. This book is not only useful for those new to the material, but the format is also very good to be used as a reference. While his explanation of the different patterns is very good, I believe it's his principles and test-driven-development philosophy that are the real gems in this book. These are principles and practices that every developer should be familiar with. In fact, this is a great approach for junior developers so they can become disciplined. In a world where everyone seems to be an "Architect", I'm amazed at how many don't convey and don't practice similiar thoughts. If you can't open yourself up to the "model your idea up on a white-board, erase, code test case, code logic" mentality, then it will be very difficult to see the intuitiveness of Bob's writing. Bob has provided a job-aid to all of us and we'd be in a lot better shape as software professionals if we followed just a few of these principles.
| 
