Pattern Languages of Program Design 3

Paperback (Print)
Buy New
Buy New from BN.com
$36.97
Used and New from Other Sellers
Used and New from Other Sellers
from $7.57
Usually ships in 1-2 business days
(Save 81%)
Other sellers (Paperback)
  • All (14) from $7.57   
  • New (7) from $25.33   
  • Used (7) from $7.57   

Overview

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

Read More Show Less

Editorial Reviews

Peter Roth

The Patterners

A software design pattern is a solution to a particular computing problem. Each pattern has, in general, four parts: the pattern name, the problem to be solved, the solution provided by the pattern, and the trade-offs. Familiarity with patterns makes software design "easier," because large concepts can be dealt with using the patterns, rather than reinventing the wheel in each program.

A recent presentation on patterns comes via Addison-Wesley's Corporate & Professional imprint. The production quality of Pattern Languages Of Program Design 3, edited by Robert Martin, Dirk Riehle, and Frank Buschmann, is excellent, and the binding easily endured the two months I spent reviewing the text. Most importantly, because you'll find yourself reading the text with pen in hand, the pages are of sufficient thickness to take marginalia and highlighting without bleed-through. This is a nice book.

The editors have selected 29 papers presented at the Pattern Languages Of Programming (PLoP) '96 and EuroPLoP '96 conferences. The papers are grouped such that the book has ten parts, which range from the introductory General Purpose Design Patterns to the more ethereal Patterns On Patterns. Each part is briefly introduced by one of the editors. The book is brought to completion with a brief bio of each contributor, and an index.

A large number of people were involved with the production of this volume. Many papers are the product of a team of authors. The papers were worked into the conferences by "shepherds," whose clarifications and assistance were thankfully received by several authors. The editors invoked a large number of reviewers (a half page list). As one would expect with this many eyes reading and commenting on the text, it is in good English, with complete, declarative sentences. My personal bugbear -- typos -- are almost nonexistent.

The majority of the authors use graphics to present alternative views of their pattern. These include Booch cloud, class structure, object sequence, collaboration, and interaction diagrams. Unfortunately, the symbols used on the diagrams are not explicit in the text; the reader is assumed to be familiar with them. There is also a smattering of jargon, so I recommend that you not start your pattern education with this text. Rather, begin with Design Patterns by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley, 1995), which is referenced in 33 of the 39 sections of the book. (By the way, you'll also need to know that those authors are known in the patterns community as the "Gang of Four," abbreviated "GoF.") A familiarity with James Coplien's writings also would be helpful, and you should have a reading knowledge of C++ and Smalltalk.

There is no disk or CD provided with the book. This deficiency is more than overcome by the inclusion of the authors' e-mail addresses, their web-page URLs, and several Internet list servers and news groups.

So what's new? In the Introduction, Brian Foote writes,

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

This is to be taken in the sense that the patterns presented in the book are not being exposed to the light of day for the first time, but rather have been used in actual working programs. Because the patterns document things that work, it is reasonable to conclude that they may work in other situations, perhaps yours. The advantage of studying published patterns is, of course, the benefit of having a few more minds applied to your problem at a minimal cost.

I found the Asynchronous Visitor pattern to be the most interesting. It corrects a problem inherent in the GoF Visitor pattern, the purpose of which is to allow one to indirectly modify a class hierarchy. After further study and argument, it has been found that the Visitor pattern introduces a dependency cycle of the base class on all its derivatives, so any additions to the Visitor class require a recompilation of the entire hierarchy. The Asynchronous Visitor pattern separates the Visitor class from the hierarchy, and hence minimizes the need for recompilation, which can be quite dear in C++ programs.

I draw two lessons from the chapter on the Asynchronous Visitor pattern:

It is a "better" pattern than Visitor. Patterns can't be applied blindly -- some experience with them is necessary. A pattern that "works" (Visitor) may not work all that well after all.

These lessons belie the stated purpose of The Software Pattern Series, inscribed on the back of the frontispiece: "Books in the series distill experience...into a form that software professionals can apply immediately." This is too hasty by at least two measures:

It takes time to assimilate and evaluate patterns merely to ascertain if they are suitable for use. It would be rare for a professional program designer to accept anything into a program immediately, since one must live with the side effects of both good and hasty decisions.

A reader therefore does well to evaluate both the patterns and the claims thereof.

Although written somewhat tongue-in-cheek, the last paper in the book, "A Pattern Language for Pattern Writing" by Meszaros and Doble, might be the easiest place to start studying the book. It shows how to put a pattern article together, and hence makes it easier to take the other papers apart.

The least useful patterns were those devoted to the process of software development, that is, how people interact to produce the stuff. These patterns are devoted to evolving frameworks, designing in teams, and testing. These papers are mostly "good advice" that has been presented at far greater length, and with greater clarity in other venues: Peopleware by DeMarco and Lister jumps to mind.

PLoPD3 is no novel. It is a difficult book to read, for you are reading the documentation and code of other programs. It is not a book to skim once and shelve. Rather, I suggest you read a paper, try to imagine how you would use the pattern, and try some of the sample code. Try to imagine some of the problems that will occur if you use the pattern. With this admittedly conservative approach, the book will take a few months to read.--Dr. Dobb's Electronic Review of Computer Books

Read More Show Less

Product Details

  • ISBN-13: 9780201310115
  • Publisher: Addison-Wesley
  • Publication date: 9/30/1997
  • Series: Software Patterns Series
  • Edition description: Older Edition
  • Pages: 634
  • Product dimensions: 7.10 (w) x 9.00 (h) x 1.60 (d)

Meet the Author

Robert C. Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming.

Dirk Riehle is a software engineer at Ubilab. He is involved in the Geo project, which is setting up a reflective distributed object-oriented software architecture.

Frank Buschmann is a software engineer at Siemens, where he focuses on object-oriented technology, software reuse, and patterns. He is a member of the ANSI C++ standards committee.

Read More Show Less

Read an Excerpt

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.

Read More Show Less

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

Read More Show Less

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

Read More Show Less

Introduction

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. Firstand 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.


Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)