Pat says: This is a famous book, and students should be exposed to it for that reason alone.  In a quick skim-through, I found quite a bit of food for thought, but as a battle-scarred developer with years of experience in embedded software development at AT&T, I do sympathize with a recent statement by a Penn faculty (besides myself) who shall remain nameless here, and I quote: "I'm extremely skeptical about the design pattern school, having worked closely with design pattern-imbued programmers in large projects."

Reading this book is harder than expected because it does not focus on a specific programming language, but tries to generalize across the set of (then common) object-oriented languages.

The design approach to a given problem is often constrained highly by domain-specific problems such as performance constraints in real-time software, or the need to comply with (possibly annoying and useless) industry standards.  There is little doubt in my mind that programmers do use design patterns anyway as they gain experience and see a lot of programs.  But I think a student's time might just as well be spent reading someone else's good code about a problem of interest in the domain at hand, rather than theorizing.  This book's fault, if it has one, is that of generalization; while it's worth trying to generalize, it isn't always helpful in the end.  In fact, it can be quite unhelpful to try to force an elegant-seeming solution to fit around a problem where ugly details are sticking out of the other side of the container.  The problem is that old saying, "the devil is in the details".