I wanted to make use of some of the ideas i learned from this book, but did not work in the kind of programing shop where I could do that. ( )

What the book is about
Have you ever heard of design patterns? These are essential elements of object-oriented programming, and every programmer should know them.
The book will introduce you to this notion of design patterns. You will discover what they are, why every programmer should know them, how they can improve your programming, etc…
Then, the book will cover in a structured way and in detail each of the design patterns.

My thoughts
I think this book is good. But, there is too much information about each of the design patterns. It's impossible to remember everything or to take note of everything.
That's why I see this book more as a cheatsheet, or something you open only when you have a specific need and you want detailed information about something. In this case, if I want information about the Visitor pattern, I just open the book and I will find everything I need.
Also, this book is a lot theoretical. It includes some code examples, but not a lot. This is neither good nor bad because it meets different needs.

Who should read it
I think every programmer who has never heard about design patterns should read it. If you have ever heard of design patterns, it's not so useful to read this book, but it's useful to own it so that if you need information about one design pattern one day you can just find all the information you need in the book. ( )

Great as always.
Very dense, a lot of food for thought. ( )

after A Pattern Language / Christopher Alexander classics

Design Patterns is a very important reference and its contents are also important, but it is a rather dull book to read. This is mainly because the bulk of the book contains a catalog of patterns. Like most catalogs, it works better when you come to it looking for something specific.

I have two main criticisms of the patterns themselves, both of which stem more from the time the book was written than from any inherent problems with the patterns. First, each pattern contains a list of benefits and consequences. This section never considers the pattern from the view point of testability. This is a pity because most of the patterns, in my opinion, serve to make the relevant components easier to test.

A more serious complaint is that many of the patterns show their age by suggesting implementation inheritance as a good way of implementing these patterns. While implementation inheritance still has its place in the programmer's toolbox, current wisdom shies away from using it merely because it is convenient. Instead, current belief leans more toward preferring interfaces (in the Java sense of only defining operations and not implementations) and reserves implementation inheritance for when it provides a tangible benefit.

That said, most of the patterns still have a useful core, even if some of the details of pattern structure or implementation should be modified to fit better into common practice. Just remember though, if you want to read through it you need will power or a reading group (preferably both). ( )