Description

• Copyright 1998
• Dimensions: 7-1/4" x 9-1/4"
• Pages: 656
• Edition: 1st

• Book
• ISBN-10: 0-201-31011-2
• ISBN-13: 978-0-201-31011-5

Patterns remain one of the most important new technologies contributing to software engineering, system design, and development. All indications are that patterns will continue to grow in significance as more and more developers rely on reusable design patterns to help them achieve quick, cost-effective delivery of applications. This volume is a collection of the current best practices and trends in the patterns community. The patterns contained in this book provide effective, tested, and versatile software design solutions for developers in all domains, institutions, and organizations.

The third in a series of books documenting patterns for professional software developers, this volume continues the tradition of informational excellence established by the first two volumes. Pattern Languages of Program Design 3 differs from the previous two volumes in that it includes international submissions, gathering the best papers from both PloP '96 and EuroPLoP '96. It covers a wide range of pattern-related subjects, and patterns are arranged by topic so software engineers can easily select those of greatest relevance to their needs and application domains. This book goes beyond teaching software engineers that design patterns are powerful tools to impart understanding--it shows where and when patterns are best applied.

0201310112B04062001



Sample Content

Table of Contents

Preface.

I. GENERAL PURPOSE DESIGN PATTERNS.

 1. Null Object, Bobby Woolf.
 2. Manager, Peter Sommerlad.
 3. Product Trader, Dirk Bäumer and Dirk Riehle.
 4. Type Object, Ralph Johnson and Bobby Woolf.
 5. Sponsor-Selector, Eugene Wallingford.
 6. Extension Object, Erich Gamma.

II. VARIATIONS ON DESIGN PATTERNS.

 7. Acyclic Visitor, Robert C. Martin.
 8. Default and Extrinsic Visitor, Martin E. Nordberg III.
 9. State Patterns, Paul Dyson and Bruce Anderson.

III. ARCHITECTURAL PATTERNS.

10. Recursive Control, Bran Selic.
11. Bureaucracy, Dirk Riehle.

IV. DISTRIBUTION PATTERNS.

12. Acceptor and Connector, Douglas E. Schmidt.
13. Bodyguard, Fernando Das Neves and Alejandra Garrido.
14. Asynchronous Completion Token, Irfan Pyarali, Timothy H. Harrison, and Douglas C. Schmidt.
15. Object Recovery, António Rito Silva, João Dias Pereira, and José Alves Marques.
16. Patterns for Logging Diagnostic Messages, Neil B. Harrison.

V. PERSISTENCE PATTERNS.

17. Serializer, Dirk Riehle, Wolf Siberski, Dirk Bäumer, Daniel Megert, and Heinz Z’llighoven.
18. Accessing Relational Databases, Wolfgang Keller and Jens Coldewey.

VI. USER INTERFACE PATTERNS.

19. A Pattern Language for Developing Form-Style Windows, Mark Bradac and Becky Fletcher.

VII. PROGRAMMING PATTERNS.

20. Double-Checked Locking, Douglas E. Schmidt and Tim Harrison.
21. External Polymorphism, Chris Cleeland, Douglas E. Schmidt, and Tim Harrison.

VIII. DOMAIN-SPECIFIC PATTERNS.

22. Business Patterns of Association Objects, Lorraine L. Boyd.
23. A Pattern Language of Transport Systems (Point and Route), Liping Zhao and Ted Foster.
24. The Points and Deviations Pattern Language of Fire Alarm, Systems Peter Molin and Lennart Ohlsson.

IX. PROCESS PATTERNS.

25. The Selfish Class, Brian Foote and Joseph Yoder.
26. Patterns for Evolving Frameworks, Don Roberts and Ralph Johnson.
27. Patterns for Designing in Teams, Charles Weir.
28. Patterns for System Testing, David E. DeLano and Linda Rising.

X. PATTERNS ON PATTERNS.

29. A Pattern Language for Pattern Writing, Gerard Meszaros and Jim Doble.
Index. 0201310112T04062001

Preface

This is the third in the series of PLoPD books; and it represents something of a departure from the previous two. This is the first book in the PLoPD series in which fewer than half of the papers submitted at the corresponding PLoP conferences have been published. This is also the first PLoPD book in which papers from more than one conference have been published. There were over 80 papers submitted to PLoP '96 and EuroPLoP '96 and there was no way that we could publish them all. Therefore we had the unhappy task of deciding which of those papers not to publish. This task was not easy since all the papers submitted were of very high quality (Something we have come to expect from the PLoP conferences). Fortunately, our burden was lightened by all the folks who helped out with the review and selection process.

The process of creating this book.

We recruited a veritable army of reviewers, and each of the 80+ papers was reviewed by three of them. The reviewers' recommendations were then passed on to the three editors (Dirk Riehle, Frank Buschmann, and Robert Martin). Then began a rather long and heated exchange between us. None of us had any problem being choosy; and, indeed, the three of us settled on a large core of papers to be published. But there were a few papers that we did not agree upon. And thereupon laid the long and arduous process of defining the final contents of this book. None of us think that this book is perfect; but all of us think that it is a top-notch collection of superb papers.

What were our selection criteria? The choice of papers was constrained by our target audience: software engineers. First and foremost the papers in this volume had to be of interest to this audience. Although patterns about music are interesting to musicians, we did not think that they should be included here. Secondly, the papers had to be of practical value to our audience. Although papers of abstract theory are certainly interesting, we gave preference to papers that provided techniques or tools that would be of immediate use to our audience. Finally, the papers should be patterns. There were lots of good papers that were written about software engineering, but we gave preference to those that described patterns related to software engineering.

To be sure, these criteria were not unambiguously stated up front. Like all high quality projects, the requirements evolved during development. It was during the book definition process that we learned about each other's expectations and visions for the book. And it was during this process that our own expectations and visions were changed through discussion and argument. All in all, it was a very rewarding, if somewhat exhausting, experience.

In the spirit of Ralph Johnson's suggestion to catalog patterns as design specimens, just like biology catalogs and classifies its animal and non-animal specimens, we organized the book by topic. It comprises general design patterns as well as patterns for specific technical or business domains. It also contains patterns for designing user interfaces, and helping with software processes; it even contains a chapter with patterns for writing patterns. We did not distinguish between patterns and pattern languages, but focussed on putting together patterns by topic so that you can take a look and see whether these patterns are of interest to your needs and your application domains.

Design Patterns, a 1997 perspective.

It has been two years since the publication of the GoF book. During that time interest in design patterns has increased at a phenomenal rate. Today it is very unlikely that any serious software is ignorant of the concept of design patterns. There are major magazines that run regular columns about design patterns. The C++ Report runs a monthly section about design patterns. There are several other books by major authors that have been published on the topic of design patterns. All this indicates that the concept of design patterns is a significant event in the evolution of software engineering; and that it will continue to grow in significance for several years to come.

With this growth in awareness and significance comes a danger. It would be easy to switch our enthusiasm from the patterns themselves to the concept of patterns in general. This, in our opinion, would be a mistake. The use of well-worn design patterns in a given project can be of great benefit. But the force fit of lots of different patterns into the same project would be worse than useless. Just because a pattern exists, does not mean the pattern should be used. A particular pattern fits into a project when there is a problem to be solved, and when that pattern properly balances the forces that impinge upon that problem. One cannot justify the use of a particular pattern just because it is a pattern. For example, an engineer can not justify the use of the Visitor pattern simply because it is a pattern in the GoF book. Design patterns are tools to be used by engineers who understand where and when those tools are best applied.

Where are your weapons?

Dr. Who is an old English science fiction television series. In the episode entitled "Hand of Destiny" a silicon based life-form is escorted into the Tardis (Dr. Who's space ship. An acronym which stands for: Time And Relative Dimensions In Space) by the Doctor. The life form looks around and exclaims: "Impressive! But where are its weapons?" The Doctor stares the silicon based life form right in the eyes, points at his temple, and says: "Here!"

Once one of us (Robert) spoke at a conference in Chicago to a rather large audience regarding design patterns. He asked all of them who had purchased the GoF book to raise their hands. About 80% of the hands went up. Then he asked everyone who had not read what they had bought to put their hands down. About half the hands went down. Then he asked everyone who could not explain the Visitor pattern to put their hands down. Nearly all the hands went down.

The patterns in this book, or in any of the excellent patterns books that have been published since 1995, do you no good if they remain in the book. They have to get into your head for them to be of real use. Some folks like to think that they can use the various patterns books as a catalog in which to look up solutions when they have problems; but this is not likely to be an effective practice. Instead, you must study the patterns and integrate them into your mental model of software design. Then, when you are designing software, the patterns will present themselves before you even know you have a design problem.

So read the patterns. Read them carefully. Make sure your weapons for attacking software design are firmly ensconced within your brain.

Acknowledgements

First of all, a very special thanks to the Hillside group for sponsoring the PLoP conferences, and for providing the motive force for these books. Without their effort and dedication there might not be any PLoPD books at all.

Thanks to Doug Schmidt whose sanity is contagious.

Thanks to Jim Coplien (cope) who reminded us that our work has a moral, as well as technological, imperative.

Thanks to John Vlissides, the series editor, for keeping his hand on the tiller while the storm raged.

Thanks to Walter Tichy for keeping us humble.

Finally, from Bob a personal thanks to Dirk Riehle and Frank Buschmann for keeping him from bouncing too far off the wall.

We would also like to thank all the authors who submitted papers to PLoP and EuroPLoP '96, the shepherds who helped guide those papers to the conference, and the reviewers who helped the editors make the hard choices. Their names follow:

Alan O'Callaghan, Alejandra Garrido, Alistair Cockburn, Amiram Yehudai, Amnon H. Eden, Amund Aarsten, Andreas R¸ping, AntÛnio Rito Silva, Becky Fletcher, BenoÓt Garbinato, Bernd-Uwe Pagel, Bindu Rama Rao, Bjˆrn Eiderb‰ck, Bobby Woolf, Bran Selic, Brian Foote, Bruce Anderson, Bruce Lombardi, Charles D. Knutson, Charles Weir, Chris Cleeland, Chrystalla C. Alexandrou, Clazien Wezeman, Curtis R. Cook, D Janaki Ram, D. Schwabe, Daniel A. Rawsthorne, Daniel Megert, David E. DeLano, Davide Brugali, Dirk B‰umer, Don Roberts, Douglas C. Schmidt, Edward J. Posnak, Elizabeth A. Kendall, Erich Gamma, Eugene Wallingford, Eyun Eli Jacobsen, Fernando das Neves,

G. Rossi, George A. Papadopoulos, Gerard Meszaros, Giuseppe Menga, Hans Rohnert, Harrick M. Vin, Heinz Z¸llighoven, Ilir Kondo, Irfan Pyarali, James Noble, Jan Newmarch, Jean Tessier, Jean-Lin Pacherie, Jean-Marc JÈzÈquel, Jens Coldewey, Jim Doble, Jim Lee, Jo„o Pereira, John Brant, John Vlissides, John W. Gilbert, JosÈ Alves Marques, Joseph Gil, Joseph Yoder, K N Anantha Raman, K N Guruprasad, Ken Auer, Kent Beck, Kyle Brown, Lennart Ohlsson, Leonor Barroca, Linda Rising, Lipling Zhao, Lizette Vel·zquez, Lorraine L. Boyd, Margaret T. Malkoun, Mario Winter, Mark Bradac, Martin E. Nordberg III, Martin Fowler, Michel de Champlain, Neil B.Harrison, Omer Karacan, Palle Nowack, Pascal Felber, Paul Dyson, Pedro Henriques, Peter H. Feiler, Peter Molin, Peter Sommerlad, Prashant Jain, R. Greg Lavender, R. J. A. Buhr, Rachid Guerraoui, Ralph Johnson, Reinhard M¸ller, Robert Engel, Robert Hirschfeld, Robert S. Hanmer, Rudolph K. Keller, Serge Demeyer, Steve Berczuk, Suchitra Raman, Suzanne Robertson, Ted Foster, Theo Dirk Meijler, Thomas K¸hne, Tim Harrison, Timothy A. Budd, Todd Coram, Walter F. Tichy, Wolf Siberski, and Wolfgang Keller.

Robert C. Martin, Chicago, June 1997.
Dirk Riehle, Zurich, June 1997.
Frank Buschmann, Munich, June 1997.


0201310112P04062001

Introduction

Hybrid Vigor and Footprints in the Snow

    We hope, of course, that many of the people who 
read, and use this language, will try to improve these 
patterns -- will put their energy to work, in 
the task of finding more true, more profound invariants -- and 
we hope that gradually these more true patterns, 
which are slowly discovered, as time goes on, will enter a 
common language, which all of us can share."
         Christopher Alexander et. al. A Pattern Language, xv.
         [Alexander et. al 1977]

    

v v v

What's new here is that there's nothing new here.

Patterns are about what works. Patterns give us a way to talk about what works.

Stewart Brand, in his book How Buildings Learn, [Brand 1994] recounts an oft-told (and perhaps apocryphal) tale of a brilliant, but lazy college planner who built a new campus with no sidewalks at all. She waited for the first winter and photographed where people made paths in the snow between the buildings. The next spring, she put the pavement there. Patterns have this sort of quality. Instead of making brash, premature, and probably erroneous conjectures about what might work, pattern writers look for footprints in the snow, and describe what has worked already.

Talking about what works seems so obvious. Why hasn't this happened before? Why is it happening now?

In the academic world, there is a relentless focus on the new. Academics are veritable novelty vampires, who consume new ideas rapaciously. This phenomenon is particularly acute in computer science, where four-month old technology can be deemed "traditional". Patterns, on the other hand, are dispatches from the trenches about what works. They are about recurring solutions, and if a lot of people have been doing something for a long time, it can't be new, can it?

Because patterns are drawn from experience, they are not about invention or creation per se. Pattern writers don't play God, and create the universe in their image, but they do play Adam and Eve, by choosing names for the denizens of their garden. This is a responsibility that is not to be taken lightly.

Ralph Johnson has pointed out that it is common in other academic disciplines to study subject matter that the researchers did not themselves create. Entomologists collect butterflies and categorize them, and talk about these categories, and why they exist. However, biologists do not create new forms of life (at least, not yet). Still, biologists can gather specimens, make observations, and discover categories without having to worry about being accused of plagiarizing nature. Similarly, pattern writers can play not only Adam and Eve, but Carolus Linnaeus as well.

Computer science is a young discipline that has for too long seen itself as a stepchild of mathematics and electrical engineering. While computer scientists spent their first generation trying to behave like mathematicians and physicists, they too often ignored the rich vein of indigenous subject matter that ran directly under their feet: the experience that can be gleaned from real programmers and real systems. It is a sign of new maturity and self-reliance that we can now borrow from architecture, biology, literature, communications, and, at last, even ourselves.

The patterns movement is in tune with a distintly '90s cultural Zeitgeist. It is a second-generation phenomenon, like Java. It's about innovation in an age of sampling. Sampling has become a way of life on the World Wide Web. Popular musicians in the '90s often borrow shamelessly from their predecessors, not by merely quoting their phrases, but by using digital samplers to directly embed snippets of other people's actual performances into their own work. Their artistic predecessors had broken every rule of harmony and composition as they strove unrelentingly for originality. Now, this exploration of increasingly inhospitable new frontiers is over. Musicians in the '90s solved their originality problem by ignoring it. Instead, they built on the past by combining existing elements of their artistic heritage in new ways.

From the beginning, one of the things that has distinguished the patterns community has been its aggressive disregard for originality. A good sign that something new is happening is when people say that new music, poetry, or art isn't really music, poetry, or art at all. People argue as to whether patterns are really computer science, or even research. If what we are doing isn't computer science, it ought to be.

v v v

While academia may be addicted to change, industry, on the other hand, certainly has no problem with things that are tested and proven. It does have a problem with talking about them. Why indeed should people in industry give their architectural insights away to their competitors? Why give away the store? What is gained by paying people to write patterns instead of programs? These are legitimate concerns. We certainly don't expect PLoP to become a trade secrets show-and-tell conference.

PLoP USA is held at Allerton House, a turn-of-the-century manor surrounded by statues and formal gardens, set on a wooded estate on the banks of the Sangamon River, in rural Illinois. Pattern pilgrims travel through forty miles of corn and soybeans to reach Robert Allerton's monument to architectural eccentricity. In making this journey, through some of the richest farmland in the world, the term "hybrid vigor" somehow comes to mind.

PLoP draws people and patterns from what must seem, on the surface, like an unworkably diverse pool. PLoP draws academics and practitioners, managers and programmers, consultants and students, and even the odd building contractor. Why the smorgasbord? Why is the patterns community so eclectic? Maybe it's because there really are underlying architectural principles beneath seemingly disparate areas. Maybe there really are good ideas that scale, generalize, and travel well.

Nature invented cross-pollination to propagate successful innovations throughout a population rapidly. Farmers and horticulturists later learned that they could manipulate this process to create hybrids in order to counteract inbreeding and enhance characteristics they found desirable. The introduction of new genetic material from distant relatives frequently produced exceptionally productive and robust new varieties, hence the term "hybrid vigor".

Perhaps a caching scheme I heard about in a pattern culled from an application that looks nothing like the ones I write will, when examined in the proper light, be just what I need in one of my programs six months from now. This potential for hybridization is one reason why industry should be interested in patterns. The cross-pollination among the unique cross-section of industry and academia at PLoP allows best practices to be quickly and widely disseminated, thereby bringing a healthy touch of hybrid vigor to all involved. So patterns people can play not only Adam and Eve, and Carolus Linnaeus, but Luther Burbank as well. Industry has more to gain than to fear from a real engineering handbook for software architecture.

v v v

That which a culture glorifies will flourish. Unfortunately, software architecture is often hidden. The patterns community provides software architects with something they have never had before: an audience.

Software architecture is often an afterthought. We reward results, even if they are the result of slash-and-burn engineering, and result in sprawling, shantytown architectures. For too long, software architects have toiled like the medieval artisans who carefully carved the backs of their gargoyles, knowing that high above the ground, their artistry could be seen only by God. Now that we have a forum where practitioners, and theorists, and programmers, and professors can get together to laud that which has worked, the architectural as well as aesthetic achievements of heretofore anonymous software designers can start to get some belated and well-deserved (mortal) recognition.

Software architecture is the next level up from languages and libraries. A system might have a good architecture or a bad architecture, but it can't have no architecture at all. Software architecture is just emerging as a discipline. Whether by encouraging the infrastructure for wide-scale reuse, or the emergence of the components that underlie the latest rapid prototyping environment, architecture is the key to the division of labor that characterizes mature engineering disciplines.

Reuse is an act of trust. The pioneer who blazes a trail knows if he or she turned left to avoid a two hundred-mile detour, or to avoid a fallen branch. Those who follow do not have the benefit of this insight. They know only that to continue to follow the trail, they must turn left. Architecture needs to be about ideas that can stand on their own. Designers need a vocabulary that conveys meaning without requiring an encyclopedic, white-box knowledge of each and every abstraction of everyone who uses it.

v v v

Thomas Malthus was a 19th century clergyman and economist who grimly hypothesized that successful communities would grow until their needs exceeded the resources available to sustain them. Dr. Malthus came to Allerton Park in 1996. We received over 70 submissions, and nearly 110 registrations. Our infrastructure was bursting at the seams. Our submissions were more eclectic than ever. It seems inevitable that these forces will cleave our diamond-in-the-rough along its natural fissures. Indeed, these facets are already emerging. EuroPLoP, TelePLoP, ChiliPLoP, and UP, have joined good ol' PLoP Classic USA. New books about patterns are sprouting like high-yield hybrids in the hot summer sun. The success of patterns has even turned them into a lightning rod for new academic research.

Powerful forces have been set into motion--have set us into motion. It's fascinating to contrast a design conversation today with one we might have had a few years ago. For instance, not only are the once abstruse architectural notions presented in the Gang-of-Four book [Gamma et. al. 1995] common knowledge, but they can be proposed, compared, and dismissed with one simple name. They are becoming part of a design lexicon that may well be with us for generations. The power and conciseness that this new vocabulary gives its speakers is striking. We are still a long way from having the sort of pattern language for software architecture that Alexander attempted for building. Still, three years ago, few of us really had any idea where all of this might be headed. It's hard now not to think that we are witnessing something important and enduring.

Just under a century ago, two brothers could build an airplane in a bicycle shop. Just a generation later, the engineering expertise that went into a pre-World War II warplane dwarfed any of the individuals engaged in its design. The pioneers had been supplanted by teams of superbly skilled, highly specialized collaborators who together defined the architectural lexicon and division-of-labor that allowed them to partition their work and integrate it into a working whole. They were able to divide up their work because they could discern the distinct, emerging architectural elements in their engineering domain, and the boundaries between them. Small groups of skilled designers can still juggle the pieces, but these pieces are cast at a much higher level.

In many ways, software architecture is just leaving its bicycle shop era. Brad Cox [Cox 1995] has observed, for instance, that "unlike the hardware industry, which has organized itself into a fully elaborated rainforest of mutually interdependent structures of production trees, the software industry remains stuck in the unicellular, bacterial stage of the primordial ooze."

Today, interstate highways run over the tracks left by the wheels where westbound wagon trains once rolled. The pioneers could never have conceived of the engineering effort necessary to build the spectacular bridges and tunnels we have built, nor of the machinery to move mountains of stone, concrete, and asphalt that would dwarf the pyramids. We can make their journey of months in a matter of hours or days. Yet, we did this not by blazing new trails of our own, but by looking for footprints in the snow, and putting the pavement there.

Brian Foote , Urbana, Illinois

v v v

[Alexander et. al 1977]
C. Alexander, S. Ishikawa, and M. Silverstein
A Pattern Language
Oxford University Press, Oxford, UK, 1977

[Brand 1994]
Stewart Brand
How Buildings Learn: What Happens After They're Built
Viking Press, 1994

[Cox 1995]
Brad Cox
No Silver Bullet Revisited
American Programmer Journal
November, 1995

[Gamma et. al 1995]
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Design Patterns: Elements of Reusable Object-Oriented Software
Addison-Wesley, Reading, MA, 1995


    



Updates

Submit Errata

