Design Patterns: Elements of Reusable Object-Oriented Software [Kindle Edition]

There are other advantages to this book. It isolates 23 of the most common patterns and presents them in detail. You wouldn't think that 23 patterns would be enough, but once you become adept at recognizing patterns, you'll find that a large fraction of the patterns you use in practice are among these 23. For each pattern, the book carefully presents the intent of the pattern, a motivating example, consequences of using that pattern, implementation considerations and pitfalls, sample code (C++ or Smalltalk), known uses of that pattern in real-world applications, and a list of related patterns.

Upon first reading, you will start to recognize these patterns in the frameworks you see. Upon second reading, you'll begin to see how these patterns can help you in your own designs, and may also start to see new patterns not listed in the book. Once you become familiar with the pattern concept, you will be able to originate your own patterns, which will serve you well in the future. One of the most valuable contributions of this book is that it is designed not merely to help you identify patterns, but to give you a sense of which patterns are appropriate in which contexts.

I think this book is particularly valuable to many C++ and Java programmers, because of the dynamic and flexible design philosophy it follows. (Its two fundamental principles of reusable OO design are: "Program to an interface, not an implementation" and "Favor object composition over class inheritance".) I've found that many C++ books unfortunately tend to emphasize a rather static and inflexible design philosophy. Many C++ programmers do not realize how the language and the books they've studied from have been limiting their thinking until they have been exposed to ideas from other lanugages. The authors of this book have obviously been influenced by other languages as well, especially Smalltalk, and have brought many of its best lessons to C++ design. Most Java books seem to take after the C++ books, even though Java is a more dynamic language. This book may help Java programmers take full advantage of the extra power offered by their language, if they look deeply enough into some of the lesser-known features its runtime system affords.

Last, but not least, this book is valuable because it names the patterns it uses, and so gives programmers a common vocabulary to describe design concepts, rather than particular implementations. You'll find yourself saying things like, "That would be a good use for a Decorator", or "Should we use a Facade or a Mediator in this case?" I encourage readers of this book to use this vocabulary with other programmers.

In summary, this is one of the few books that I think belongs on every programmer's "must-have" list. Not to overuse a cliche, but like object-oriented design itself, the pattern concept is one of those rare paradigm-shifts in computer programming. It is equally valuable to expert professional and novice student alike. The book has a home page at http://st-www.cs.uiuc.edu/users/patterns/DPBook/DPBook.html

I went through two of the patterns with full concentration, found mistakes in both and found they really did get in the way. Things were named or referenced in ways that just couldn't be right. I wrote to the authors about a few issues (e.g. on pg 275, Widget should reference DialogDirector, not aggregate it) and the response (Johnson, Vlissedes) was very kind and constructive. But I believe there is significant work remaining. You may think I'm being overly picky here (at issue on pg 275 is an itsy bitsy little shape), but try understanding something completely new when there is one mistake in it. You wonder if you're comprehending wrong.

I have a hunch that most folks here, pardon my presumption, who are rating high without reservation are really in love with the idea of finding patterns to design (as am I). But I wonder if they've ever really really tried to go through any of the examples at a finer resolution than a bird's eye view. The book does a lot to crystalize the dream of reusable design patterns but not as much as it could to wake us up to realizing it.

Still it's on my list of things to buy because it's darn thought-provoking. Maybe that's it's highest purpose: to announce, if only by the title, the shocking idea that there could be patterns to design, that programmers might not always have to reinvent the universe with each project. (The idea that they don't is not new, but the *fact* that they don't is making woefully slow progress.)

The big question I still have is did they pick really good patterns and objectify them with compassion and vision? Are these the very paradigms and clumps of computational power that will be in the toolbox of programmers yet unborn? Dunno. I suspect from the tactical gaffs that strategic corrections are in order.

Maybe 3 stars isn't harsh enough but it's certainly a pioneering book. I believe one significantly better will come out in the next decade. It would be nice (somehow in my rosy view of the world) if it were by some of the same guys...