Review of Head First Design Patterns
How to make this review interesting to read...
The way to make this review interesting to read is to offer some insights you can't find in the Amazon reviews. So let's skip over the obvious in just a few words. The highly creative and entertaining presentation in this book is what makes it so special. You can even see the style in the cover. The rest of the book is just like the cover – goofy images and lots of humor. The book would be half the size if you removed all the fun parts, but few people would read it. You can get the fawning praise over on Amazon.com and the book really does deserve those positive comments.
In short, the book shows how you can tackle the same programming problems using different approaches or “patterns”. It’s a book for serious Java coders but technical managers might still want to quickly skim it. Even if readers don’t remember the patterns, the book has tremendous value in driving home the point that developers should think twice about how they approach a problem and there might be a better way. Coders tend to use the first approach they think of since that's the easiest path and human nature.
OK – So the presentation is stunning and brilliant. But what about the actual content?
This is what the reviews on Amazon don’t tell you. If you look at the negative reviews of this book, they are, almost without exception, all from people who prefer to have their computer books boring. Fair enough. Lord knows that we too, here at Practicing Safe Techs, are fierce opponents of putting humor in computer books. But hardly anyone has commented on the actual content of the book. So let's mention a few cautions about this book:
Warning #1 – The weaknesses of the patterns are very lightly discussed or not mentioned at all
All of these patterns have weaknesses, but there's almost no coverage of the drawbacks. The book never tells you, for example, “the Strategy Pattern comes at the cost of many new classes and can inhibit understandability”. The book would have been greatly improved with a small box at the end of each chapter that tells the reader when they might not want to use the pattern. The authors actually do this for several patterns, but not until the very end of the book in the “Leftover Patterns” appendix. They should have done this for every pattern in the main portion of the book - not just for the small patterns in the Appendix. Understanding the weaknesses is as important as understanding the strengths of any pattern.
At the very end, the book finally discusses trade offs, but it does so only at the philosophical level. It doesn’t specifically highlight the weaknesses of the patterns it covered in the first 500 pages.
Warning #2 – The book does not prioritize the patterns
The reader is never told which patterns are very common and which are seldom used. That would be nice to know. The Decorator pattern is not often used, and when it is, the results can almost always be achieved using some other pattern. They should have presented the patterns in the order of their importance.
Warning #3 – Industry doesn’t do it that way
These patterns have been around for a long time. They are the basis for all those grand code-reuse promises we received 20 years ago in the C++ era. Those promises were never realized. Yes - if you follow the patterns in this book, you really can achieve a lot more code reuse. But in practice, industry just doesn’t follow these patterns – or at least, not over time. It’s just too tempting to use concrete classes where you should be using abstract classes, for example. It would have been very valuable had the authors offered some observations about how and where these patterns typically degenerate over time. The reader needs to know what to look out for.
The book is absolutely fantastic despite some shortcomings. They've made learning as fun as it can be. A programmer who is not aware of these patterns is like an author who not know grammar.