This review covers the book Head First Design Patterns. My ultra brief summary: BOOK GOOD, if you find this insufficient you'll have to read my complete review
This book is rated quite highly on Amazon.com – which is what sparkled my initial purchase. However, is this popularity justified? With comments like “Best way to learn Design Patterns”, “Pleasure to read” and “Great Book” you'd think that these reviews were written by the authors or this is, in fact, a good book. How much you like the book is going to depend on how well you can understand the book and how much you learn (as with any technical book).
I heard someone described the book as “Design Patterns for Teenagers”, this was due to the way the information is informally laid out in the book in a “visually rich” fashion, but, find a teenager happy to read a 600 page programming manual and...well – you'd probably bring about the end of the universe – something about paradoxes, black holes and the end of creation which I read about in, err, “A Brief History of Time”, you'd have to ask Steven Hawking about the specifics. Ummm, yeah.
Anyway as I was saying, the pages aren't filled with dense text in a 4 point font, but well arranged with plenty of pictures, diagrams and “feel good” stuff, making the book a fairly easy read. The Head First series of books have a layout which is meant to maximize your ability to learn, thus they are excellent books to learn from but are not so good as reference books.
The programming examples are in Java, as you know I'm primarily a Delphi developer and having never written any Java code in my life, excepting perhaps “hello world” one might think that I would find the book utterly confusing. Not the case, firstly Java is not particularly difficult to read and I have done some C++ which is similar, and as there are plenty of pictures, I can, if nothing else, stare blankly at those instead.
What are design patterns? The theory goes that there are certain “patterns” in program "design" that appear again and again. Rather than re-inventing them each time you can apply one of these "patterns" that was "designed" to solve your problem – or something similar. Or you can take your code and mash it and crush it and stuff it and squeeeeze until it fits one of these patterns, however as fun as this sounds it's not recommended. Design patterns are not solutions in themselves but more like templates for solutions.
Why use design patterns? If a particular problem you are trying to solve fits a design pattern you can take advantage of it – spend less time designing, coding and debugging – which equates to less time thinking – and we could all do with less of that. In addition other programmers that know about design patterns will have an easier time understanding your design and hence can more readily maintain your code (therefore they need not think as hard – and you not at all).
One annoyance I found with the book is that each chapter builds you up to a design pattern via a process (discussions, diagrams, code examples etc.) and I noticed my self saying “get to the point already!”, but only on occasion.
Why would one want to buy this book? Developer Studio does provide some support for design patterns and you do need to know them quite well before you can properly apply them to which this book does provide an easy introduction. Even without this support, I think it's worth reading about design patterns as you will get a framework (actually a series of them) to tackle difficult design problems.