This was really an excellent book. I’m hesitant to say if it is really better than other books I’ve read on design patterns simply because I question how much reader experience plays a role in getting a book like this. This is not the first book I’ve read on Design Patterns and OOP programming. However, it is the first one that I’ve really felt that I got. Now there are two possible reasons why I think I got it. First is that it is a clear well-written, well-organized book. Second, is that I actually have some experience to apply to the concepts in the book.

First off, it was indeed a good book. Theory was balanced well with examples. Theory was related with clarity, and the examples were relevant to the theory. I particularly liked the focus not on functionality, but on responsibility. I feel it gives the program more of a human quality than just a machine. Beyond the way it changes one’s perception of the program, it really I think gives more meaning to the program. The reality is that after spending months working on a program I do become somewhat attached to it. Handing that program off to someone else to maintain is not always easy. I’ve noticed that after reading this book I’ve looked at my programs as less of a set of functionality that solves a problem, and more as a set of workers, each with there own set of responsibilities, that, at a high level, solves a given problem. I kind of view it as my classes have a responsibility. That class is decomposed into the functionality necessary to perform that responsibility. At this point testing now involves straight unit tests of pieces of functionality, and something more that tests that a responsibility is performed. This seems above unit testing, but not quite integration testing. Above all, my development style has not really changed, only my way of thinking about it.

Which brings me to my next observation. Which is how my experience affected my perception of the book. I’ve read a number of OOP books that revolve around the explanation and promotion of design patterns. However, I read all of them during my first year of real day-in day-out development. They sort of planted the seeds, but I remember going into the books with so much excitement, only to come out on the other end confused and wondering what just happened.

I think I now understand though. I didn’t come out of this one dazed and confused, and I’m not convinced that it is because it was a much better book. Instead what I found throughout this book was a constant connection with my experience. As he explained the Adapter Pattern, I would think that I used this all the time, I just didn’t realize it had a name. When explaining the Bridge Pattern I’m thinking of how I could have written better applications if I had understood then what I know now. A number of years have passed between reading my first Design Patterns books and now. And those few years have been spent developing software full-time. As such Design Patterns now make sense to me. Explanations seemed to clarify or give names to what I already know conceptually, or provide ways to improve designs I have or am already working on. I feel that for me at least I had to spend time designing software without patterns to really understand how patterns can provide consistency, maintainability, and a common dictionary of ideas for developers to communicate more effectively. Overall, very much worth the read.