CELEBRATE EARTH WEEK
Save 70% on video training and simulators now through April 27*—use code EARTH. Shop now.
Design patterns have moved into the mainstream of professional software development as a highly effective means of improving the quality of software engineering, system design, and development, as well as the communication among the people building them. Patterns capture many of the best practices of software design, making them available to all software engineers.
The fifth volume in a series of books documenting patterns for professional software developers, Pattern Languages of Program Design 5 covers current software development best practices distilled by the patterns community. The material presented in the nineteen chapters of this book distills first-rate patterns, which were workshopped at recent PLoP conferences and rigorously reviewed and enhanced by leading experts in attendance. Representing the best of the conferences, these patterns provide effective, tested, and versatile software design solutions for solving real-world problems in a variety of domains.
Pattern Languages of Program Design 5 covers a wide range of topics, particularly the areas of object-oriented systems, programming techniques, temporal patterns, security, domain-oriented patterns, human-computer interaction, software management, and software patterns.
Among them, you will find patterns addressing:
As patterns continue to capture insight from many areas of practical software development, more and more developers are discovering that using patterns improves communication and helps them build better software.
Download the Sample
Chapter related to this title.
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 Patternsthe urtext of patterns in software designwas unleashed into an unsuspecting world (or at least, the OOPSLA conference) in late 1994although, 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 blueprintwell, 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 seriesthe 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 Patternsand all the work that was contemporaneous, that followed, that was inspired, or that reacted against itreally 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 editors--or, 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 coffeeand 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 industrycatalyzed, no doubt, due to the success of Design Patternsthat 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 designthat'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 solutionwhat 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.
Download the Index
file related to this title.