Book review by Ted Felix
The first edition from 1991 is one of the first handful of O-O design books, and possibly one of the best. It has been sitting on my bookshelf since it was published. I originally took an O-O design class at IBM, and this book was the text. I never even opened it. Now as I skim through it, I'm seeing that this is a really well done book that helps make the transition from the old-school to the new.
The second edition continues the tradition of the original in making the connection from the old to the new, but using the UML's Activity Diagram (a combination of the old flowchart and data flow diagram) instead of data flow diagrams. Compare the first edition's section 9.10 with the second edition's 14.12. The old-school is still there, although the names have changed which might make it more difficult to track down the history (and the bibliography is quite poor). They do mention flowcharts, data flow diagrams, structured analysis, and structured design, however they pass them off as not being worth as much as they had thought in the first edition.
The rather thorough introduction to the UML made it clear to me why few projects use it properly. The UML is too formal, complete, disjoint, and different from conventional programming languages. When talking software architecture, they abandon the UML in favor of an informal diagram as suggested in Software Architecture in Practice (Len Bass, et al. 2003). The UML does offer some new concepts that might come in handy such as association classes and in this respect is worth learning.
The architecture and design portions of the book go over all the important concepts such as the different kinds of classes (domain vs. application (UI) vs. implementation, concrete vs. conceptual, interfaces, boundary classes, controllers...). Twice they say what I've been saying for years: An application designed using only one of these kinds of classes doesn't do anything (once referring to domain classes, and once referring to "mechanisms" or library classes). You need a combination of several of them to create an application. I wish I could have read this book in the mid-90's. Unfortunately, the first edition isn't quite as good as this. The second is a big improvement.
I always find the unsubstantiated claims of O-O promoters to be rather funny. On page 21, the authors claim (without any examples) that proper O-O design makes a system more resilient to change. I disagree. I believe that the most important factor in making a system resilient is accurately predicting the future. If you know what's coming, you can organize the code to make it easier to deal with those changes. Larman's Applying UML and Patterns is better in this respect as it gives "Low Representational Gap" as the main reason why O-O is good and also agrees with me on predicting the future.
This book introduced me to the word "reification". It's a handy word to describe changing something that is not an object into an object. For example, a controller object consists mostly of behavior. However, behavior is not an object. By grouping related behavior into a class, it is "reified", or made into an object. Beginners at O-O development have to resist the urge to reify everything. Reification must be done with care and discipline.
My main gripe with the book is its lousy bibliography. If you are hoping to do further research into the origins of O-O thought, this book's bibliographies will not get you there. The bibliography is spread throughout the chapters making it hard to find out if certain important works are referenced. It gives the impression that this is not a well-researched book at all.
My recommendation: If you do object oriented development, you must read at least one OO architecture and design book. This is a good one but Larman's Applying UML and Patterns is better. Blaha/Rumbaugh's UML section is interesting, but shouldn't be taken too seriously. The analysis and design sections, particularly chapter 14 (System Design) and chapter 15 (Class Design), are excellent and really give you a feel for how OO should be done. The chapters on implementation and databases are interesting, but may or may not be very useful. Being fairly academic and concise, it will get you up to speed quickly without much fluff, but it is a bit impenetrable at times. Beginners will probably want something gentler. Intermediate O-O developers will learn quite a bit. Experts will find the bibliography seriously lacking.
Of the classics on Object Oriented Design, this is the first one to be brought up to date. We may have to wait a while before we have Jacobson or Booch to choose from. The original edition of Jacobson is in many ways better than this book even though it doesn't cover UML. However, Larman's Applying UML and Patterns beats this book and all the classics hands down. I would recommend reading it instead of this book. I'm betting Larman's book is one of the main reasons why none of the classics have been updated. It is better than all the classics combined.
Read from 11/23/2005 to 12/22/2005.
<- Back to my software books page.
Copyright ©2006, Ted Felix. Disclaimer