Book review by Ted Felix
This is the best book on object oriented design I've read. I first noticed the book when I saw it in Code Complete's list of books that are required reading to qualify for "intermediate" developer level at Steve McConnell's company. The reason I didn't run right out and read it was the title. The title is so filled with buzzwords that it is a pretty big turn-off to those of us who have been doing object oriented development for many years and have seen how worthless buzzwords tend to be. Surprisingly, this is a book about the sensible use of UML and patterns, not the overuse and abuse we've all seen so many times. The title also seems to indicate that this is a beginner's book. While the book is a good introduction, it is also good enough to teach experts a few things. It is very hard to get the information that Larman covers from experience and all the other books out there. Larman is clearly the right person to bring together all the literature and his experience as a consultant into this extraordinarily clear presentation.
Even after having done object oriented development for 16 years, I still learned quite a bit. Here are the highlights:
This is something I'd suspected for years. One of the reasons object oriented approaches are so valuable is that they allow the design of the software to closely match the real world. This makes it easier to understand what the code is doing, given an understanding of the problem domain. This doesn't mean that there should be no distance between the problem domain and the software design. Rather, we should try to keep the gap between the two small.
"Notice that although this design class diagram is not the same as the domain model, some class names and content are similar. In this way, OO designs and languages can support a lower representational gap between the software components and our mental models of a domain. That improves comprehension." (pg 11)
The GRASP Patterns are the most valuable part of this book. Larman brings together all the fundamental good advice ("best practices" is such an abused term) about object oriented design into a set of 9 patterns. The book is primarily dedicated to exploring how the GRASP Patterns guide the design of object oriented software.
My favorite pattern was "Pure Fabrication" (pg 424). In this pattern, you create a class out of thin air for the purpose of improving the cohesion of the classes in a system. This is needed when a class starts to grow too big. A good example would be a real-world class, like a "Car" class, that starts out very simple. Maybe it only has a "color" attribute. Since it is so small, it would be ok to include Display() and SaveToFile() functions within the Car class. But, as the Car class grows, those functions would grow as well. Eventually, the Car class will become pretty large. By Pure Fabrication, we could split off classes to take care of reading/writing Cars to files and displaying them on the screen.
Larman advocates a separation of UI code from application logic and domain model code. His variation on this approach has the UI code knowing about the application logic, but not the other way around. Callbacks (à la Observer) are used to allow the application logic to update the UI.
One of my biggest complaints about design diagrams is the static/dynamic view separation. I need a way to combine the static view of the software along with the dynamic view to get my point across. Apparently, Larman does too. He presents a technique where pseudocode is embedded in notes within UML class diagrams to show how the behavior of methods might be implemented. He then goes on to use this approach quite a bit throughout the book. I had never seen this before, but to me it makes UML diagrams potentially much more useful.
"When there are alternative design choices, take a closer look at the cohesion and coupling implications of the alternatives and possibly at the future evolution pressures on the alternatives. Choose an alternative with good cohesion, coupling, and stability in the presence of likely future changes." (pg 341)
It's a great book, but it does have a few minor problems. There were numerous typos and grammatical errors. I had to keep a pencil handy at all times. I don't think there was anything that affected the accuracy of the information presented.
Acronyms were used long after they had been introduced. There was no acronym list handy in the glossary or index to make it easy to remember what the acronyms stood for. SSD stands for System Sequence Diagram, and is covered in chapter 10 (pg 173). A DCD is a Design Class Diagram covered on pages 10 and 251.
The word "skillful" was overused.
These are minor issues, though.
If you do Object Oriented Design or Programming, you've got to read this book.
Read from 7/27/2006 to 9/28/2006.
<- Back to my software books page.
Copyright ©2006, Ted Felix. Disclaimer