HAPPY BOOKSGIVING
Use code BOOKSGIVING during checkout to save 40%-55% on books and eBooks. Shop now.
Register your product to gain access to bonus material or receive a coupon.
This succinct, example-driven book empowers software developers who are using design patterns, arguably today's most popular object-oriented programming concept. Design Patterns' co-author John Vlissides blends his intimate knowledge of the pattern development process with practical techniques for better pattern application. The result is a thought-provoking guide that will help you improve your next software design by putting patterns to work successfully.
Pattern Hatching demystifies the fine points of patterns, placing them in the broader context of basic object-oriented design principles. It dispels many of the misconceptions about patterns that have spread in the software development community--clearly articulating what patterns are and how they ease the development process. The book also presents themes and variations on several established patterns, yielding many new insights. With the instruction in this book, you will become better able to tailor patterns to the design problem at hand.
I'll never forget how I felt one autumn afternoon back in 1994. I had just received an e-mail message from Stan Lippman, then-editor-in-chief of C++ Report, extending me an offer to write a bimonthly column for that magazine.
We were the merest acquaintances, having met earlier in the year when he toured the Watson Lab. We had chatted briefly about his work on development tools and about the GoF's work on patterns. Unlike most people at the time, Stan was familiar with the pattern concept-he had read successive preprints of Design Patterns and had encouraging things to say about it. Be that as it may, the conversation drifted quickly toward the art of writing in general; and as it did, I remember feeling increasingly pretentious, like I was out of my league. Here was Stan, noted columnist and author of two highly successful books, discussing his craft with a rank amateur. I wasn't sure if he was enjoying our conversation or just tolerating it until his next appointment. (I've since learned that Stan's tolerance is surpassed only by his sincerity!)
Yet those feelings of inadequacy were nothing compared to my reaction to his e-mail a few months later. I experienced a strange combination of elation and terror at the prospect of writing regularly for an international audience. Could I keep it up for more than a couple of installments? Would people care what I had to say? What did I have to say? And if I said it, would it help anyone?
I indulged my fears for nearly an hour. Then some of my Dad's admonitions started coming back to me: Self-consciousness breeds paralysis, I was told, not in so many words. Focus on the fundamentals, and everything else will follow. "Just do it," he had said, well before Nike would.
So I did.
Choosing a theme was easy enough. By that point I had been knee-deep in pattern research for nearly three years. We had recently completed the Design Patterns book, but we all knew it was far from the final word on the topic. A column would be a great forum for expounding on that material, for extending it, and for addressing new issues as they arose. It didn't hurt that a column could help sales too-if it did the book justice.
Now, after more than a dozen installments of my "Pattern Hatching" column, I think it's safe to say my fears were unfounded. I'm never at a loss for something to write, and I always have fun writing it. I've also received lots of encouraging feedback from people worldwide, including recurring solicitations for old installments. After a while that got me to thinking about a one-stop shop for my columns, along with any other pattern stuff I had that was useful and had gone unpublished.
This book is meant to fill that bill. In it you'll find thoughts and ideas from the first three years of my column-writing career, including everything I've published in C++ Report and Object Magazine, plus a smattering of new insights. I've arranged it in logical order rather than temporally so that it reads as a book should. That was easier than it might have been, because many of the articles were part of this or that series, but it still took some doing. I hope you enjoy the result.
AcknowledgmentsAs always, there are many people to thank for multifarious assistance. First and foremost are my fellow Gang of Four members-Erich Gamma, Richard Helm, and Ralph Johnson. Each one offered valuable feedback at one point or another, the sum of which made this a much different (and certainly better) book. It's a rare privilege to work with people who so complement one another, and I'm very grateful for it.
They weren't unrivaled in their help, however. Several others took time to plow through rough drafts in search of non sequiturs, faux pas, and the all-too-familiar lapsus calami. These indomitable souls include Bruce Anderson, Bard Bloom, Frank Buschmann, Jim Coplien, Rey Crisostomo, Wim De Pauw, Kirk Knoernschild, John Lakos, Doug Lea, Bob Martin, Dirk Riehle, Doug Schmidt, and Peri Tarr. An added word of thanks goes to Jim, my alter ego in the Report, for his gracious Foreword to this book and just for being an all-around inspiring guy.
Next come the total strangers who have e-written me questions, comments, corrections, and good-natured chides. There are many in this category, but I'll list only those whom I have quoted or whose comments were relevant to this volume: Mark Betz, Laurion Burchall, Chris Clark, Richard Gyger, Michael Hittesdorf, Michael McCosker, Scott Meyers, Tim Peierls, Paul Pelletier, Ranjiv Sharma, David Van Camp, Gerolf Wendland, and Barbara Zino. And even though I haven't identified the rest of you, please realize that I'm no less obliged for your input.
Finally, I thank two families, one natural, the other professional, for supporting me in untold ways. I owe both a great debt.
J.V.Errata for Pattern Hatching: Design Patterns Applied
p. 55
The "two-way mapping" should be between User and Group instances, not User and Node instances.
p. 56
The destructor has a spurious return value.
p. 67
The implementation of Singleton::instance() should be:
Singleton* Singleton::instance () {
Singleton* theSingleton = _destroyer.getDoomed();
if (!theSingleton) {
_destroyer.setDoomed(theSingleton = new Singleton);
}
return theSingleton;
}