Pattern Languages of Program Design 3
- By Robert C. Martin, Dirk Riehle, Frank Buschmann
- Published Oct 7, 1997 by Addison-Wesley Professional. Part of the Software Patterns Series series.
- Copyright 1998
- Dimensions: 7-3/8x9-1/4
- Pages: 656
- Edition: 1st
- ISBN-10: 0-201-31011-2
- ISBN-13: 978-0-201-31011-5
Register your product to gain access to bonus material or receive a coupon.
Product Author Bios
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.
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.
6 of 6 people found the following review helpful
Enjoyable book for the friends of software patterns,
This review is from: Pattern Languages of Program Design 3 (v. 3) (Paperback)This book has quite some prerequisites for its potential readers. You should have a working knowledge of the patterns of the too basic books ("Design Patterns" by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides and "Pattern-Oriented Software Architecture" by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal). It is helpful to have the too previous conference books as a reference nearby. Yes and you have to cope with C++ (when did you use it last time) and Smalltalk.
If you are happy with this, you get rewarded by a rich set of ideas and insights. The book just draws you in. This is a conference book by many authors. But due to their shepherd and writers workshop efforts the book nearly reads like being written by one author/author team. The level is excellent. Reading this book is a nice way to spend your time.
2 of 2 people found the following review helpful
Many nuggets of software development knowledge, however you need some knowledge of design patterns to understand it,
This review is from: Pattern Languages of Program Design 3 (v. 3) (Paperback)While patterns are an inherent part of the human experience, using them in software development is a recent phenomenon. The seminal event was the publication of the book, "Design Patterns: Elements of Reusable Object-Oriented Software", by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. A Group so well-known that they are commonly referred to as the "Gang of Four," or GoF for short.
A design pattern is a metamodel for a solution. However, being a solution to a set of conditions common to many different problems, design patterns are very hard to learn. Even the GoF admit this in the preface of their book. "Don't worry if you don't understand this book completely on the first reading. We didn't understand it all on the first writing!" There are two fundamental reasons for this. The first is that the identification of a design pattern requires that one recognize a common abstraction among a set of abstractions. There is principle about great mathematicians that... Read more
12 of 18 people found the following review helpful
A Lot of good stuff,
This review is from: Pattern Languages of Program Design 3 (v. 3) (Paperback)When looking at the PLOPD serie, it become obvious that material become more and more mature. We'll find in this book good design patterns we can directly apply in our everyday work. Yo will probably found that all patterns are not usefull, but only a subset, but it's however an enough reason to buy this book.
› See all 3 customer reviews...
Praise For Pattern Languages of Program Design 3
"There are many nuggets to be mined from this book. However, be prepared to go slow and occasionally be discouraged. "
Table of Contents
I. GENERAL PURPOSE DESIGN PATTERNS.
II. VARIATIONS ON DESIGN PATTERNS.
III. ARCHITECTURAL PATTERNS.
IV. DISTRIBUTION PATTERNS.
V. PERSISTENCE PATTERNS.
VI. USER INTERFACE PATTERNS.
VII. PROGRAMMING PATTERNS.
VIII. DOMAIN-SPECIFIC PATTERNS.
IX. PROCESS PATTERNS.
X. PATTERNS ON PATTERNS.
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.
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, Bjrn Eiderbck, 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 Bumer, 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, Joo 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.
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]
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
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.
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
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.
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.
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
[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
This book includes free shipping!
Get access to thousands of books and training videos about technology, professional development and digital media from more than 40 leading publishers, including Addison-Wesley, Prentice Hall, Cisco Press, IBM Press, O'Reilly Media, Wrox, Apress, and many more. If you continue your subscription after your 30-day trial, you can receive 30% off a monthly subscription to the Safari Library for up to 12 months. That's a total savings of $199.