New Brief 8/13/97, 2:24:32PM by NetAttaché Light

Software Patterns

James O. Coplien

Interest in patterns has fostered one of the fastest-growing communities in contemporary software design. Like many emergent software techniques in recent history-structured programming, data abstraction, and objects-they have captured the imagination of many in the industry. Most of these techniques fail to fulfill the expectations that propel them to such prominence, partly because immature ideas are exposed to the market prematurely, partly because of opportunism, and partly because a hopeful (or desperate) market yearns for the one key solution to all problems. This is a recipe not only for mismatched expectations but for misinformation, which in turn fuels expectations and so on.

I would like to claim that this Briefing is the final word on patterns: the arbiter of disagreements and splinter perspectives, the definitive word on how excited we should or should not be about patterns. It is not and cannot be such a work. The Hillside Group, one loosely affiliated group of designers who are actively pursuing pattern solutions to industry problems, is brought together by a vision which itself accommodates and celebrates a variety of individual visions. Dialogue continues on what is and is not a pattern, on what is and is not a good pattern; this work does not cap that dialogue but contributes to it. The pattern community values diversity: there are many things called "patterns" that share a small core of techniques, principles, and values, all of which have proven useful to programmers. There are, in fact, several pattern communities, some of them quite decoupled from each other. This paper attempts to capture the practice and foundations of an (admittedly ill-defined) mainstream pattern culture.

This work is an apologia, both in the sense of "apology" and of a defensio or "defense." When we discuss patterns in public, we bear responsibility for setting reasonable expectations for patterns. Most new techniques are heralded by expectations that outstrip what the technique can deliver, and the danger for patterns to fall into this trap is immense. Patterns touch critical issues that are central to strategic software development, and they are important for that reason. But they are also just documentation, and rely on the insights of the people who create and use them. It is important to view patterns as one more tool in the designer's tool kit. Their success depends on people, and particularly on the most human aspects of software development and its culture. This paper accentuates that perspective: we want to accentuate the value of people in design, and to diminish hype.

Though this Briefing is the work of a single author, it reflects the work of dozens of individuals. It draws directly on the contributions of many pattern writers and pattern thinkers, which takes the material outside my immediate sphere of thought. In fact, the following pages probably bear more of my colleagues' words than my own; primarily, I provide the arrangement and the glue that tie the pieces together.

This is consistent with another important agenda of the pattern community: we would much rather read, use, and write patterns than talk or write about patterns. Premature abstraction is dangerous; it too easily distracts us from the ends to which we should be aspiring. So, although this briefing is an early attempt to abstract principles from the pattern community and explores the frontiers of its value system, it is grounded in "real stuff." Enjoy it as an exposition of patterns. Focus on the patterns, think about them, and understand them-then read the surrounding analyses and commentary.

I've let many commentators challenge and shape my own thoughts while writing this Briefing. Thanks to Bruce Anderson, Kent Beck, Stephen Berczuk, Frank Buschmann, Paul Chisholm, Ward Cunningham, Brandon Goldfedder, Janel Green, Richard Gabriel, Norm Kerth, Gerard Meszaros, Hans Rohnert, Doug Schmidt, and Bjarne Stroustrup for their comments, examples, and suggestions.

A Word on Alexander

Patterns have their roots in urban design and building architecture in the work of Christopher Alexander, the indisputable inspiration for the software patterns groundswell. Most pattern publications pay him homage; sales of his architecture books have soared in the software community. The vocabulary of software patterns-forces, the term pattern itself, pattern languages-comes from Alexander.

However, most of the pattern community has let go of literal interpretations of Alexander. The pragmatics of software development seem to dictate iterative development; Alexander would have us apply patterns in monotonic, progressive order. All analogies break down somewhere. While early pattern pioneers looked for Alexanderian analogies under every rock, software pattern literature is taking increasingly bold departures from Alexanderian structures and forms. Experience with patterns has borne out ties to other sources, including earlier work in computer science on literate programing.

Alexander's greatest legacy to the pattern community is his vision and value system, but his vision is so foreign to most software practice that it is often lost in technical dimension of patterns. One goal of this briefing is to highlight the pattern value system so it is more broadly understood and appreciated.

Organization of the Briefing

The paper is organized to start with the central questions of patterns, moving on to more refined and advanced issues later on. The sections include:

1. What Is a Pattern? This section looks at the prevailing definitions of patterns, both historically and in contemporary software patterns. It also explains why patterns are important.
2. What Are Pattern Languages? Building on Section 1, this section defines collections of patterns called pattern languages, the most important application of patterns to system design.
3. Pattern Domains. This section gives examples of software disciplines that are using patterns.
4. Classifying Patterns. With hundreds of patterns, how do designers find the ones they're looking for? This section investigates the organizing principles currently being used for software patterns.
5. Pattern Pragmatics. This section outlines the business benefits of patterns and how to introduce patterns into a development culture.
6. Generativity. Generativity is what distinguishes patterns from rules. It is a subtle but important component of the pattern culture.
7. The Pattern Value System. A value system has arisen within the pattern community that restores dignity to programmers. We also recognize several important legal and ethical issues.
8. History. How patterns found their way from Alexander's work into contemporary software architecture; the people and the events leading up to today.

What Is a Pattern?

A pattern is a piece of literature that describes a design problem and a general solution for the problem in a particular context. Alexander tells us: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing. (Alexander, 1979: p. 247)

I like to relate this definition to dress patterns. I could tell you how to make a dress by specifying the route of a scissors through a piece of cloth in terms of angles and lengths of cut. Or, I could give you a pattern. Reading the specification, you would have no idea what was being built or if you had built the right thing when you were finished. The pattern foreshadows the product: it is the rule for making the thing, but it is also, in many respects, the thing itself. The document that describes a particular decoupling arrangement in object-oriented programs, we call "the Bridge pattern" (Gamma et al., 1995); each instance of that arrangement in the program is also called "a Bridge." Also:

"These patterns in our minds are, more or less, mental images of the patterns in the world: they are abstract representations of the very morphological rules which define the patterns in the world.

However, in one respect they are very different. The patterns in the world merely exist. But the same patterns in our minds are dynamic. They have force. They are generative. They tell us what to do; they tell us how we shall, or may, generate them; and they tell us too, that under certain circumstances, we must create them.

Each pattern is a rule which describes what you have to do to generate the entity which it defines." (Alexander, 1979: pp. 181-182)

Above, Alexander refers to patterns as a "three-part rule"; he also calls patterns "rules of thumb" in Timeless Way. Patterns are more than just the rule: they encompass the literature that describes the rule and helps it unfold for our use.

Ward Cunningham adds the following metaphor-patterns are more like recipes than plans: "I like to make the distinction between a plan and a recipe. A plan can be reverse engineered from a building but a recipe can't (easily) be reverse engineered from a cake. Our genome is a recipe, not a plan. Recipes seem to serve better as a schema of complex adaptive systems." (Personal communication with Ward Cunningham, 20 February 1996.)

We observe patterns in everyday structures: in buildings, in vehicle traffic, in organizations of people, and in our software. Alexander extracted patterns from building and town structures of numerous cultures. He believed that by documenting these patterns, he could help people shape the buildings of their community to support life to its fullest. Patterns are structures that have evolved over ages of development to fulfill cultural needs. They are rules, driven by principles, that serve human and social needs. Patterns are also the documentation of these structures. Therefore, a pattern is both "a thing which happens in the world," and "the ruleŠto create that thing."

Patterns have evolved to a small number of related literary forms. In one sense, a pattern is just documentation. On the other hand, they are "just documentation" in the same sense that poetry is "just literature."

Besides, we believe that human communication is the bottleneck in software development. If the pattern literary form can help programmers communicate with their clients, their customers, and with each other, they help fill a crucial need of contemporary software development.

Patterns are not a complete design method; they capture important practices of existing methods and practices uncodified by conventional methods. They are not a CASE tool. They focus more on the human activities of design than on transformations that can blindly be automated. They are not artificial intelligence; they celebrate and encourage the human intelligence that separates people from computers.

Example: Here is a synopsis of a typical Alexanderian pattern, one of the most often-cited patterns from his book A Pattern Language:

A Place to Wait

The process of waiting has inherent conflicts in it.

One on hand, whatever people are waiting for-the doctor, an airplane, a business appointment-has built-in uncertainties, which make it inevitable that they must spend a long time hanging around, waiting, doing nothing.

On the other hand, they cannot usually afford to enjoy this time. Because it is unpredictable, they must hang at the very door. Since they never know exactly when their turn will come, they cannot even take a stroll or sit outsideŠ

Therefore:

"In places where people end up waiting, create a situation which makes the waiting positive. Fuse the waiting with some other activity-newspaper, coffee, pool tables, horseshoes; something which draws people in who are not simply waiting. And also the opposite: make a place which can draw a person waiting into a reverie; quiet; a positive silence." (Alexander et al., 1977: pp. 707-711)

We also see patterns in the software we write. Patterns are recurring design problem/solution pairs. The most important patterns capture important structures, practices, and techniques that are key competencies in a given field, but which are not yet widely known.

The Relationship of Patterns to...

Patterns are like many other design formalisms but are distinct from most common formalisms in subtle ways. Panu Viljamaa explains:

"Patterns are related to but different from: paradigms, idioms, principles, heuristics, architectures, frameworks, role-models.

You could say that a paradigm is a very abstract pattern, or style of work that can be followed consistently throughout the system. Idiom is a language-specific typical way of using and combining elementary building blocks. Principle is an invariant that can hold globally, or "always"; it could be a synonym for "design rule." Heuristics aid decision making, without claiming absolute goodness for the actions suggested. Heuristics could be used to choose among multiple alternative patterns. Architecture refers to the total structure of an application, possibly described by the multiple patterns involved. Patterns have been called "micro-architectures." Frameworks refer to collections of concrete classes working together to accomplish a given parameterizable task. Role-models describe a single coordinated collaboration among multiple participants (the framework classes can serve in multiple roles simultaneously). Role-models may be the closest thing to the formalization of patterns." (Viljaama, 1995)

Why Do We need to Capture Patterns?

Most would agree that the pattern discipline tries to capture important empirical design information. (The pattern community is certainly not the first to do this; for a discussion of past related efforts, see (Gamma et al., 1995: p. 357) Patterns have a different emphasis than most reuse programs or design catalogues: they tend to capture broader abstractions. In the spirit of Alexander's patterns, they make up for lapses in the memory of the contemporary software design culture, and they capture structure not immediately apparent from the code or from most system design documents.

Patterns capture obscure but important practice. Patterns capture established practices that remain obscure in the broad practice of a given domain. The intuitiveness of patterns is paradoxical. Many patterns have their roots in the work of early adaptors of a new technology or the first architects of a system. Many of these patterns attack problems in subtle ways, which makes it difficult to cast them in the framework of the predominate constructs of the technology or system. For example, in C++, reference counting would be a pattern, while the specific language features used to implement it are just that, language features, independent of reference counting per se. Bjarne Stroustrup foresaw the need for reference counting in C++. Many C++ language features-such as constructors and destructors (which serve other needs as well) and overloaded assignment-anticipate this need. But when people first learn C++, they learn it in terms of its language parts (classes, procedures, and objects) or in terms of object-oriented design principles that lead to a good class partitioning.

Patterns work at many levels of detail. We tend to think of reference counting as a detail, but programmers who don't know how to implement it properly will never be viable C++ programmers. Though reference counting is a low-level construct, we can use patterns to capture its key design principles in an abstract form. A pattern is abstract because it approaches the problem at a suitably general level, although the solution may entail details. A good solution has enough detail that the designer knows what to do, but it is general enough to address a broad context.

Patterns capture hidden structure. Patterns cut across the predominant partitionings of the subject area. Many Alexanderian patterns talk about the relationship between streets and houses (Entrance Transition), between houses and houses (Row Houses), between rooms and rooms (Varied Ceiling Heights), or between a room and its interfaces (Light on Two Sides of Every Room). They rarely focus on the properties of a single architectural artifact alone. Good software patterns are the same way: they address system problems and relationships that are obscured by a perspective from inside any of the parts. Early object-oriented design techniques magnified this myopic view of systems, and contemporary methods aren't much better. Patterns complement object-oriented design methods to capture the important constructs that cut across objects.

These "deep" components of architecture and design are larger than any architectural building blocks such as procedures or objects. Such constructs are often obscure to the day-to-day practitioner because the building materials-objects, modules, and procedures-don't highlight them. Some of these patterns are intricate and perhaps detailed-like reference counting or the structure of stairs in castle towers-yet such patterns permeate the structures they help create. The architect put such structures in place to fulfill a need, but such structures and the rationale behind them are soon lost to history. Patterns capture these structures and decisions.