Pattern Languages of Program Design 2

Description

• Copyright 1996
• Dimensions: 7-1/2" x 9-1/4"
• Pages: 624
• Edition: 1st

• Book
• ISBN-10: 0-201-89527-7
• ISBN-13: 978-0-201-89527-8

"Having expertise is one thing; conveying it to others is quite another. Patterns do just that."

Patterns are a literary form with roots in literate programming, in a design movement of the same name in contemporary architecture, and in the practices common to the ageless literature of any culture.

This volume, with contributions from the biggest names in the patterns community, is the second in a series documenting patterns for professional software developers. These patterns capture solutions to a plethora of recurring problems in software design and development, including language-specific patterns and idioms; general- and special-purpose patterns; architectural patterns; process and organizational patterns; expositional patterns; and patterns for concurrent programming, distributed systems, and reactive systems. This new collection not only reveals secrets of great software professionals but also makes those secrets easy to apply to your own work.

0201895277B04062001



Sample Content

Table of Contents

I. LANGUAGE-SPECIFIC PATTERNS AND IDIOMS.

 1. Localized Ownership: Managing Dynamic Objects in C++.
 2. Lazy Optimization: Patterns for Efficient Smalltalk Programming.
 3. Partitioning Smalltalk Code into ENVY/Developer Components.

II. GENERAL-PURPOSE PATTERNS.

 4. Command Processor.
 5. Implementation Patterns for the Observer Pattern.
 6. Patterns for Encapsulating Class Trees.
 7. The Proxy Design Pattern Revisited.
 8. MOODS: Models for Object-Oriented Design of State.
 9. Shopper.

III. SPECIAL-PURPOSE PATTERNS.

10. Detachable Inspector/Removable: A Structural Pattern for Designing Transparent Layered Services.
11. Design Patterns for Object-Oriented Hypermedia Applications.
12. Organizational Multiplexing: Patterns for Processing Satellite Telemetry with Distributed Teams.
13. Backup Pattern: Designing Redundancy in Object-Oriented Software.
14. Crossing Chasms: A Pattern Language for Object-RDBMS Integration.
15. Transactions and Accounts.

IV. ARCHITECTURAL PATTERNS.

16. Some Patterns for Software Architectures.
17. Reflection.
18. Evolution, Architecture, and Metamorphosis.

V. PROCESS AND ORGANIZATION.

19. Prioritizing Forces in Software Design.
20. Decision Deferral and Capture Pattern Language.
21. Organizational Patterns for Teams.
22. Accountability and Organizational Structures.
23. EPISODES: A Pattern Language of Competitive Development.

VI. EXPOSITION.

24. Patterns for Classroom Education.
25. Demo Prep: A Pattern Language for the Preparation of Software Demonstrations.
26. A Pattern Language for an Essay-Based Web Site.

VII. CONCURRENT PROGRAMMING/DISTRIBUTED SYSTEMS.

27. Half-Sync/Half-Async: An Architectural Pattern for Efficient and Well-Structured Concurrent I/O.
28. Resource Exchanger: A Behavioral Pattern for Low-Overhead Concurrent Resource Management.
29. The Client-Dispatcher-Server Design Pattern.
30. Active Object: An Object Behavioral Pattern for Concurrent Programming.
31. Selecting Locking Designs for Parallel Programs.

VIII. REACTIVE SYSTEMS.

32. Object-Oriented Design Patterns in Reactive Systems.
33. Fault-Tolerant Telecommunication System Patterns.
34. Improving Responsiveness in Interactive Applications Using Queues.
35. A Pattern Language for Improving the Capacity of Reactive Systems. 0201895277T04062001

Preface

An idea is like a seed blowing in the wind: it has little significance until it lands, takes root, and starts to grow. The idea of patterns, blown about the software field for two decades, has finally landed and begun to flourish. The 1994 Pattern Languages on Programming conference (PLoP '94) marked the germination of the pattern movement as the first conference dedicated to patterns in software. The following year saw publication of several pattern books, magazines rushed to print pattern articles, and patterns surfaced at mainstream software engineering and object-oriented conferences.

Then came PLoP '95, which was as different from its predecessor as a seedling differs from a young plant: it was more robust, its roots went deeper, and it was better attuned to its environment. The emphasis shifted from "What are patterns all about?" to "What makes a pattern good, and a good pattern better?" This is a profound shift, a sign of rapid maturing in people's thinking about patterns. It is a shift away from introspection toward a healthy activism. Many now appreciate that a pattern's value is in neither its discovery nor its definition but in its relevance, its quality, its impact. Patterns in software are as much about great literature as they are about technology.

Writing patterns sounds simple but isn't. The struggle is twofold: recognizing our own wisdom in recurring design problems, and communicating that wisdom effectively.

The authors of these chapters know a great deal about the struggle. It starts with reflection on the problems one has solved recurringly; then characterizing the essence of the recurring solution; and then writing the characterization down. But that's just the beginning. A pattern is invariably useless if it isn't reshaped through criticism, and that's where PLoP comes in. A paper submitted to PLoP enters a "shepherding process" where reviewers iterate with the author(s) to improve the paper. A submission may go through several iterations before it is accepted or rejected.

The struggle continues at PLoP. Papers are not presented there in any traditional sense. Rather, each is reviewed in a "writers' workshop," in which the author listens to readers discuss the paper. He or she is not allowed to participate in the discussion—that would contaminate the process with editorial input unavailable to other readerships. The goal of the workshop is to help the author improve the paper, not defend it.

The author goes home with one more chance to revise the work before submitting it for final review. Papers that clear this last hurdle are included here. Each had to survive the equivalent of thorns, storms, and locusts before blooming as a chapter in this book.

With seeds and new ideas, you never know exactly how they'll grow. Many vines have sprouted from the pattern seed, each growing independently but along one of two paths. Some grow in the path blazed by Christopher Alexander Alexander+77, Alexander79, reflecting his seminal work on patterns of building architecture. Alexander structured his patterns hierarchically into a system he called a "pattern language." But like vines left to find their own way, these Alexandrian-style papers adapt the form to their needs: they deviate from the path when it suits them.

Other vines head in a path blazed by the "Gang of Four" (GOF), the nickname for the authors of the first book on software patterns Gamma+95. These pioneers discovered the value of isolated patterns that capture wisdom in object-oriented software design. Their patterns are larger, more highly structured, and much less interdependent than Alexander's. They have helped many software developers recognize and exploit the benefits of patterns, and they've inspired many more to attempt writing patterns of their own.

This book presents numerous specimens from these paths. As you study each chapter, ask yourself which path suits you best, and why. Look carefully at the style, the format, the problems posed, the forces resolved, the consequences and drawbacks of each pattern.

Then act. A vibrant pattern community requires everyone's participation. Have you found patterns that fit your work? If so, please try them out. Do you find wisdom here that's worth sharing with your colleagues? Please let them know. Can you identify wisdom you've acquired that needs documenting? Please write it down, and have others critique it. And please consider submitting it to an upcoming PLoP!

No book materializes without help from people behind the scenes, but PLoP calls for extraordinary effort. The members of the Hillside Group organized the conference. Brian Foote and his student colleagues from the University of Illinois Urbana-Champaign proved invaluable as they assembled the papers, copied and distributed them repeatedly, and helped run the event with good cheer. The shepherds lived up to their name as selfless overseers of their authoring flocks. The contributions of nonauthor PLoP participants also need acknowledgment, for PLoP is not a passive listening experience; reading multiple papers and giving careful, constructive feedback is hard work. Many thanks to you all.

As in the previous book in this series Coplien+95, we have avoided tampering with details of form and layout in each author's work, even as we yearned for typographical coherence. So our friends at Addison-Wesley are to be doubly commended for their achievement. Deborah Lafferty guided the production effort with a gentle but firm hand; her ability to keep projects on schedule continues to amaze. Rojean Wagner and the staff at Editorial Services of New England were challenged by many an electronic format and emerged victorious. Special thanks to Tom Stone, who took a risk and gave a fledgling movement a voice.

Finally, we recognize the people most critical to this book's success, the pattern authors themselves. They have chosen to share their wisdom with the rest of us, and they sacrifice a great deal in the process. It takes courage and dedication to spend time revealing what could well be one's competitive advantage. We extend heartfelt thanks on behalf of all who will benefit from their labors.

0201895277P04062001

Introduction

Richard Gabriel

Repetition, Generativity, and Patterns

Repetition--a Foucault pendulum, seawaves north of Santa Cruz, the shapely, curved stride of a young woman--attracts us--a steady R&B beat, night lullabies. Repetition--rhyming poetry, pre-dawn coffee--defines our lives--suppertime, weekends, evenings out.

When we were born, the world, fresh, contained no repetitions. An infant first smiles at his mother's return not because it is her but because her presence repeats; later he smiles because the she who returns is the same she. I take my daughter to the bus stop at 8:20 a.m. every day, and as we stop she waits a minute then looks up the road to see the bus come over the ridgetop. She expects the bus at a particular time and feels safe and human when it does--out of sorts and stressed when it does not.

We understand all there is for us to understand through repeated parts and portions. Grammar is our regularized grunting, song is our stylized noisemaking, human society is our patterned gene stuff. We live by recognizing and using recurrences, by relying on what happens over and over. Unpredictability when not sought is feared.

Recurrence works because actions, characteristics, and relations that are noticeable repeat. Every act--every thing--contains not only the noticed repeated parts but also attendant, variable portions. The recurrent parts stand out because our minds (our brains?) are constructed that way.

Repetition as mantra is how we learn: 2x8 is 16, 3x8 is 24, 4x8 is 32. When I spelled "stillness" wrong in the 5th grade, I wrote it 100 times on the board. When I play squash and mis-hit or misdirect the ball, I chant, "follow through, follow through, you idiot." A mantra of simple things. The magic of the chant--enchantment; inward song--incantation. When the rhythm of repetition begins, the body sways; when the repetition of chant continues, sometimes the chanter cannot stop. Repetition is power.

What repeats is important and reveals commonality. What isn't repeated is variable and can be highlighted or hidden. Repetition makes us feel secure and variation makes us feel free. Abstraction reveals and revels in what is common, the repetition, and what is abstract is defined by the repeated. The remainder, in science, basks behind the veil of ignorance, and the remainder, in computing, is filled in as missing. Abstractions is what we know as long as what is repeated has the magic of enchantment and song of incantation.

But, what of the mantra "follow through, follow through"? Insistence of rhythm is a mnemonic--in ancient times laws were expressed in incantatory rhythms--and remembering and teaching are what we intend by the incantation. The law of follow-through is hard to forget--it's a law, though, that makes little sense: where is its enchantment? How can advice about what to do after you hit a ball make any difference to what happens when you hit it, or before?

The advice must work--because we hear it all the time--but how can it work? Here's how: If you plan to contact the ball at a particular point, your muscles will naturally begin slowing down just before you get there--perhaps to guard against the jolt. When you try to slow down the forward motion of your arm, muscles opposed to that motion contract to counteract. Your arm, then, moves with "noise", jiggling up and down, circling around; and power moving forward drops. Amplify this by the length of the racket. Problems.

When you follow through, your arm is aiming at a point well beyond where the racket will contact the ball, so there is no deceleration. "Don't decelerate, don't decelerate, you idiot!" It might make a mantra worth repeating, but it isn't advice you can take.

This mantra generates the effect we want--just as a seed generates the flower which eventually blossoms. Just as the wind in the sand generates dune designs and sidewinding sinews and ripples of grains of sand. The power of generative activities is cousin to that of repetition. Give a person something that can be done, and it will be done. Science loves a clever explanation--the gyroscopic forces generated by the front wheel of a bicycle cause the proper lean when you turn--but the clever explanation is merely clever, and really only good for a pleasant magazine article or MIT macho talk.

Generative mantras have the psychological power of ritual coupled with the physical power of algorithm. Ritual builds on our need for repetition and predictability, ritual is the basis of superstition--if you step with your left foot at the top of the dugout, rub toward the business end of the bat with the pine rag, dig a 3" trench to stand in with your right toe, you will not strike out. Ritual calms--the ritual of petting a dog lowers blood pressure below resting levels, makes stutterers speak clearly.

Rituals, repetitions, recurrences: These are simply patterns, the repeated parts, the familiar signposts that tame frightening variations. You don't know what the pitcher will throw, but you know how you will prepare as you walk to the plate. Rituals, like the advice to follow through, are things people can follow.

Software--is it something we can learn to produce by scientific study? Will type systems with nice semantics make it easy to produce and maintain the 5-million-line telecom switching system? Will an additional 30% in performance from unboxing data in a higher-order programming language unleash productivity in the softwareworkplace?

I don't think so. Such work will help a few dedicated researchers achieve tenure and assure a comfortable life for their long-enduring families, but you might as well tell a novice tennis player about how muscles decelerate and ask them to repeat their new stroke 20 times.

The work of the Hillside group is to remind us that people in teams and groups write software, and that in the absence of rituals and repetitions, recurrences, every step of the way for the individual is invention and creation. Software engineering is not yet engineering and won't be, cannot be, for decades if not centuries, because we cannot yet recognize the important, repeatable parts. When we do we will have patterns--recurrences, predictability.

Is it really possible we cannot yet recognize the repeatable parts? For several years I traveled to Paris every few months, and my good friend, Jerome, would always take me to the brasserie where he'd order oysters. Whenever I tasted them, all I could discern was salt water, fat, and sometimes grit. Jerome didn't skimp, and many times we had Locmariaquer oysters, but I ate the smallest polite number I could get away with.

Years later I visited Point Reyes Station in California, and my friend and I ordered oysters--Hog Island Sweetwaters. They're farmed in Tomales Bay where the river enters the bay, and they are only slightly salty. Suddenly I could taste oystertaste, sweet and lightly eccentric, muscularly hard, central. The next day--guarding against oddities--we ate oysters somewhere else, and once more I enjoyed them. The next year or so I sampled oysters whenever I could, and even when they weren't the Sweetwaters, I could taste the hint of oystertaste and could enjoy that part of it--the repeated part.

Two years ago Jerome and I were in Portland, Oregon, and I took him to Jake's where we dined on 5 dozen oysters of many types. He smiled and ordered champagne for the two of us.

I needed to learn to recognize the repeated parts--it took years and luck. Something as basic as flavor--I had to learn to taste it. Before that, oysters tasted like poison.

Software tastes like poison. Patterns, possibly, will reveal the sweetwaters.

Patterns embody the repetitions and recurrences within software; they provide the lonely developer with rituals and familiarity, and prevent him or



Updates

Submit Errata

