I purchased this book based on the glowing reviews found here, but I must say that my opinion of it is not as positive.
I find it amazing how deeply the pattern mentality has interwoven itself into computer science. While this book does have some useful advice for finding, and more importantly, preventing bugs from appearing in your code in the first place, shoehorning the information into a pattern format served as no more than justification for turning ~30 informative pages into 200. While a book is certainly more than its page count, here is a rough breakdown of how some space is utilized in this book:
- 50 pages explaining testing, extreme programming, and bugs in general. While some of this was useful for explaining the bug prevention methods later in the book, much of it was filler, including 7(!) pages of code detailing a questionable kitchen-sink application interface which has absolutely NO bearing on any of the examples or information in the book what so ever
- a 6 page troubleshooting reference that's roughly duplicated by a 10 page diagnostic checklist later in the book, neither of which provides much utility
- 120 pages explain the patterns themselves. While this may sound reasonably meaty, the patterns are often defined multiple times and in very similar ways, are put into a wordy pattern format, and each has an unnecessary summary 1-2 pages long. Not much effort is made to provide differing explanations of a pattern if the original wording doesn't make the meaning clear to you. The cures and preventions within these sections are where the most useful information will be found. Some of the code examples could be shortened and replaced with a second example in a different context.
I also found one of the examples questionable. The author used an example of the difficulties in conveying meaning with a Stack interface. As a Stack is a data structure, would you not create an abstract class instead of an interface in the first place?
Within this same Stack example, the author indicates in a few places that good documentation for this interface would be important to prevent mistakes in the implementation. Would it not be better to refactor the interface so that the implementers have a harder time making these mistakes in the first place? For example, the logic for a pop() method could be implemented by the abstract class and within that pop() method one could execute abstract isEmpty() and remove MostRecentItem() methods (or similar) that the inheritor must implement. In this fashion you encapsulate the logic of the pop() method, allowing the implementer to only be concerned with its own data.
I would only recommend this book to the most voracious reader and would suggest investigating other options instead.