Read an Excerpt
On the first day of EuroPLoP, my workshop said to me, "Delete everything on page three."
It is strange for us to realize that the design patterns movement in software design is at least ten years old. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides' Design Patterns—the urtext of patterns in software design—was unleashed into an unsuspecting world (or at least, the OOPSLA conference) in late 1994—although, following in the grand tradition of book publishers, its copyright date is 1995. Jim Coplien's Software Patterns, and the first volume (by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal) in the enduring Patterns of Software Architecture followed in 1996, setting the template or the blueprint—well, the pattern for what would follow. Inspired by these large-scale efforts, many other authors have also taken up the cause of writing patterns, centered around the Pattern Languages of Programming conference series—the first, PLoP in Monticello, Illinois, beginning in 1994 followed by EuroPLoP beginning at Kloster Irsee in 1995, and then expanding to a series of conferences held worldwide. We are all older: many of us have much less hair than we did back then.
Design Patterns—and all the work that was contemporaneous, that followed, that was inspired, or that reacted against it—really has two key values. First, to understand and to catalogue successful, proven software designs. Second, to explain and name those designs so that they can be understood, communicated, and adopted by others. To that end, software designs are described as "patterns":small, independent, interdependent pieces of a design that can be combined in many ways with many other patterns and programming techniques to generate many designs for whole programs, just as words in a language may be combined in many ways to generate an infinity of sentences, paragraphs, novels, or book prefaces. This book, and the Pattern Languages of Program Design series of which this is the latest volume, are a testament to the flexibility, diversity, and openness of patterns and the community that has grown up around them.
On the second day of Europlop, my workshop said to me, "Too many patterns."
This volume represents the fifth installment in a series that collects first-rate patterns from Pattern Languages of Programs conferences. These conferences are unique in that they consist of working sessions. Instead of presenting their work in front of a passive and sometimes dormant audience, pattern authors receive feedback from their peers. During writer's workshops, a group of pattern authors discusses a draft and provides constructive criticism to the author.
All the papers in this book were workshopped at PLoP conferences from 1998 through 2004. We invited top submissions from PLoP and ChiliPLoP (USA), EuroPLoP and VikingPLoP (Europe), KoalaPLoP (Australia), SugarLoaf PLoP (Brazil), and MensorePLoP (Japan) conferences. To maintain the tradition of previous PLoPD volumes while adding unique color to this collection, the editing team was comprised of three editors with different backgrounds (and also from different continents), who are themselves pattern authors and long-time members of the patterns community.
Current and past pattern authors welcomed the PLoPD5 call for contributions with enthusiasm. Consequently, we received over 70 papers to be considered for this volume. The submissions covered architecture, analysis, and design patterns on a wide range of topics, including aspects, Web-based applications, security, middleware, distributed workflow, finite state machines, patterns about patterns (i.e., meta-patterns), and others. To tackle this repertoire, we enlisted seasoned members of the pattern community to help us with the selection process. Each submission was reviewed for quality as well as fit by at least three reviewers and ultimately the decision of which patterns to include was made by the editorsor, as two of us (or the other two, depending on the frame of reference) would say after finishing this project, "It's all Dragos' fault."
On the third day of Europlop, my workshop said to me, "Three known uses."
How can you trust the patterns you find in this book? Why should you trust them? Part of the answer to this question is in the review process described above: The patterns in this book are not simply the crazed imaginings of a programmer who has been up too many nights and has drunk too much coffee; they are the crazed imaginings of a programmer who as been up too many nights and has drunk too much coffee—and they have been rigorously reviewed and edited by pattern experts.
Really, though, the patterns in this book stand on their own much more than on their heritage of shepherding, workshops, conferences, and reviewers. We hope that in reading them you will be able to identify the three known uses of each pattern: descriptions of at least three documented instantiations that were not designed or implemented by the author of the patterns in this book, but yet that clearly contain instances of these patterns as part of their design.
Famously, the three known uses for almost all the patterns in the original Design Patterns book were Smalltalk, ET++, and Interviews. It is a testament to the adoption of object-oriented design throughout the software industry—catalyzed, no doubt, due to the success of Design Patterns—that the three known uses of the patterns in this book are much more varied. Smalltalk and C++ graphical user interface frameworks are no doubt still lurking just under the surface, but the patterns here are much broader: object-oriented systems, middleware, management, telephony, weapons systems, jet fighters, meta-patterns, the list goes on and on. But the principle remains: these patterns are trustworthy not because the authors or us editors postulate it, but because each has been proven in at least three known practical, successful systems.
On the fourth day of Europlop, my workshop said to me, "Four forces."
A design pattern is more than just a description of a software design—that's what UML diagrams are for. Christopher Alexander, who developed patterns to describe architectural designs, defined a pattern as a "three part rule describing a solution to a problem in a context." A software pattern, however, has to be more than just a well-delineated problem and a description of a solution (with three known uses of solving that problem).
A good pattern should convince its reader first that the problem it describes is real, is hard, and is worth the time and effort of being solved properly (and thus the time and effort to write the pattern in the first place). Then, it needs to surprise the reader with its solution—what Ward Cunningham calls an "Aha! moment." Finally, a good pattern needs to make a solid argument about why the solution actually solves the problem, and how.
Alexander called the important considerations in applying a pattern the "forces." A pattern may resolve forces, rendering them unimportant after its application, or expose them where using a particular pattern requires program*mers to think about things they didn't need to think about beforehand. A good pattern will discuss not only what is good about it (its benefits, the forces it resolves) but also what is bad (its liabilities, the forces it exposes). A pattern doesn't just provide advocacy, but also argument, analysis, and rationale, convincing programmers why the solution it proposes is reliable, repeatable, and trustworthy.
On the fifth day of Europlop, my workshop said to me,"Five good things, four forces, three known uses, too many patterns, and delete everything on page three."
One hundred years ago, Albert Einstein had a "miraculous year." He published several papers that have forever changed relativity, quantum theory, and molecular theory. His paper, "On the Electrodynamics of Moving Bodies," introduced the theory of special relativity and a new way of understanding the relation between space and time.Today, most people agree that Einstein's replacing Isaac Newton's absolute space and time and regarding them as relative is a manifestation of his genius. However, genius alone would not have been enough to articulate his ideas and solve the puzzle. The formulation of special and general relativity relied on ideas developed by Einstein's predecessors and contemporaries, including Galileo Galilei, Ernst Mach, Carl Friedrich Gauss, Georg Friedrich Bernhard Riemann, Gregorio Ricci-Curbastro, Tullio Levi-Civita, Hermann Minkowski, and Hendrik Antoon Lorenz.
Although very different from theoretical physics, software development also tackles complexity. We have come a long way since the days of the first programmable machines. Today the people involved in software development must deal with complex problems on many different fronts. They build Web-based, distributed applications. They write software that powers portable devices. They build systems that receive and process events in real time. They craft applications that others extend in ways never imagined. They build software for entire product lines. They design systems that must deal with widely heterogeneous environments. Just like with special and general relativity, it would be hard or even impossible to solve all of these problems from scratch without leveraging ideas and techniques developed by others. Patterns of software, such as those presented in this volume, and the other volumes in the series, represent the best attempt we have to catalogue and explain these ideas and techniques for software design. We hope you find them useful.
To cover the breadth of the papers selected for this volume, we structured the book in six parts. Part I focuses on design and contains patterns aimed at people designing object systems. As the Internet and embedded systems continue to expand their reach, they bring with them concurrency and resource management problems; Part II contains patterns on these topics. Part III continues the shift from one to many applications and contains patterns for distributed systems. The domain-specific patterns from Part IV focus on mobile telephony and Web-based applications. Part V shifts gears to architecture and comprises patterns that tackle composition, extensibility, and reuse. Finally, Part VI offers a smorgasbord of meta-patterns for improving the quality of pattern papers and helping their authors.