Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) (Hardcover)

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

In particular, many of the patterns in this book represent highly distilled wisdom about effective solutions -- distilled so far that, unless you have implemented code that realizes the pattern in question already, you may have trouble absorbing the material. I find that programmers-to-be who dive into this book, often end up talking annoyingly about "applying patterns" without having a real grasp of how these things translate (with some distortion and compromise) into real projects.

That being said, an excellent way to bridge the gap is to read this book along with "Pattern Hatching : Design Patterns Applied" by John Vlissides. That book is a chatty companion piece for this one -- I found myself understanding how to incorporate patterns into my day-to-day design work much more after reading both books.

See: Pattern Hatching : Design Patterns Applied [also at Amazon.com]

Overall, while this book is an extremely important contribution to software developers, it is structured in a way that makes the material difficult to absorb if you aren't approaching it with substantial previous knowledge about developing software. You can start with some of the simpler patterns (Singleton, for example) and work through the harder ones, but only by implementing projects and stumbling upon these yourself will you really feel a flash of recognition as you read them in the book.

This book, on the other hand, made clear the "why" behind many software library architectures I've used, from the basic Java classes and AWT to things done in MFC, COM and the Stingray MFC extension libraries. Not only did it give an explanation, but it explicitly set out the "how-tos" on using these patterns yourself (complete with diagrams illustrating the structures and interactions), and more importantly when and when not to use particular patterns.

For me at least, the most difficult part of designing an application is not coming up with good algorithms or efficient routines, but is constructing a sensible, easy-to-maintain architecture that will hand the demands placed on it...without writing excessively convoluted code. This seems more all the more difficult the larger the application gets. The patterns in this book clarified many things which I wish I had known earlier. A few patterns that I had "discovered" through much trial-and-error and observation were set out, often in a much cleaner form than I had come up with myself. Several of the patterns in the book were immediately applicable to a project I was working on, helping to speed through what likely would have been another messy and slow design phase.

I would recommend ths book for any OO designer. At the very least, it will enable you to understand why various libraries were implemented in certain ways. At best, it will provide a useful toolkit of proven solutions enabling one to get the most out of an OO language such as C++ or Java, a toolkit that can be drawn on to solve your own architectural issues without reinventing the wheel.

The only warning I would give about this book is to reiterate the warning in the preface's very first paragraph: "This book assumes you are reasonably proficient in at least one object-oriented programming language, and you should have some experience in object-oriented design as well. You definitely shouldn't have to rush to the nearest dictionary the moment we mention 'types' and 'polymorphism', or 'interface' as opposed to 'implementation' inheritance."