1.2 Elements of Patterns

Patterns as rules of thumb and model solutions for guiding design and development could be found in the systems community before objects appeared and long before any disciplined consideration of patterns.

In activities such as structured analysis and design, concepts such as coupling and cohesion, the visual rule of Seven Plus or Minus Two, or the notion of a program architecture based around a main module all provided the kind of packaged insight that patterns offer. However, the special notion of patterns that formed the basis for software patterns came out of another field: architecture and the work of Christopher Alexander in the '60s and '70s.

While trying to establish a mathematical basis for design, Alexander started using diagrams to capture the relationships between forces that a good design solution should resolve. Although these diagrams, which he later dubbed patterns, were only a small part of the resulting book, he decided afterward that they, not the mathematics, were the key ideas.

He saw that the independence, modularity, and abstractness of his diagrams enabled them to provide a starting point for a variety of designs by themselves, in particular, by combining them as needed. And they did this in a simple, easy to use, and easy to understand way.

Subsequent books by Alexander and his partners switched the focus to patterns. They established the conceptual basis for a formal definition of patterns in architecture and the core of the idea of patterns for software development. Each pattern in the language:

describes a problem which occurs over and over again and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without doing it the same way twice. (Alexander, Ishikawa, and Silverstein 1977, x)

By the way, this is not Alexander's formal definition of a pattern, but it is a working description that lives and breathes. Alexander's definitions of pattern have a minimalist character. The one most often quoted is this:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. (1979, 247)

Short, sweet, simple and it identifies the basic elements. What's noticeable is the idea that a pattern has three parts, not just two. The added part the context is critical for fitting a solution to a problem. The context contains a system of forces that is unbalanced until the problem is resolved.

In Alexander's patterns, the solution itself is a balancing act. It becomes a way of structuring the components of what has to be crafted so that the forces that affect them and that they affect in turn are harmonized. A real solution takes into account these forces pressures, trends, needs, and constraints and balances them all in the end result.

Finally, Alexander saw that individual patterns by themselves were not enough; what was needed was a language woven of patterns. This special language would be a distillation of the experience that he and his fellow authors acquired in planning and building. And, it would be practical providing guidance and a common vocabulary for planning, designing, and building at a variety of levels, from local neighborhood improvement to constructing a house.

With these concepts, Alexander identifies all the critical elements of a pattern what they're made of and how to organize them. Software developers have taken his concepts, elaborated them, enhanced them, and argued about them. The key concepts remain the same. In most ways, only the elements and packaging are different from what Alexander described.

Before getting into a more substantial description of the essential structure of patterns and the way patterns are organized, let's look at an example of a pattern, given the information available so far. For a more detailed and colorful account of the birth of patterns and the variety of software patterns, see Chapter 9, "Patterns in Context."

1.2.1 A Simple Example

The following example is closely related to modeling, and it illustrates how a rule of thumb can be interpreted as a pattern. The rule of thumb is Seven Plus or Minus Two. Interestingly, it translates nicely into not one pattern, but two patterns that are tied together, like a miniature pattern language. It illustrates how modeling is a fundamental human activity.

Here's an informal description of the problem, context, and solution(s).

From the earliest days of software modeling, it was obvious that diagrams loaded down with many elements were not easy to understand and did not communicate well. Anyone who's seen the typical Enterprise Data Model from the halcyon period of information engineering will remember diagrams that were virtual self-parodies, on which seemingly numberless geometric shapes, lines, and squiggles seemed to be fighting for survival.

The standard way of resolving the problem of diagram overload was (and still is) to break down the model itself into a set of digestible pieces. This approach reflected a known cognitive strategy among humans, which is called chunking: organizing logically related items into groups based on patterns (cognitive patterns this time), and thinking about the groups rather than the individual items.

Model elements are chunks themselves. They abstract the multiple properties associated with each element. But this strategy creates another problem: how to chunk?

This is where Seven Plus or Minus Two comes in. Pattern recognition is itself dependent on the capabilities of human short-term memory. Individual elements in a potential cognitive pattern can be related and organized only if they are in short-term memory, and short-term memory can manage only a limited number of items. It turns out that this number, which varies only slightly depending on the circumstances, is (of course) Seven Plus or Minus Two (7 2).

So, the ideal model should consist of a number of diagrams, each of which has 7 2 main elements. In fact, the model should itself be organized into a number of levels so that each level has 7 2 diagrams. Of course, a modeling language such as the UML adds semantic and syntactical rules that can stretch the limits of the rule, but only to an extent and only within an appropriate context.

So, how does all of this look expressed as one or more patterns? I'll start with one pattern, which we can name Seven Plus or Minus Two.

The context is building diagrams of software. Within this context, we have a variety of forces that we have to balance, such as the following:

Models are made up of diagrams.
Diagrams have to communicate useful views of the real world.
A model must be comprehensive but focused.
The real world can be complex, messy, and unfocused.
Diagrams are not inherently limited in the number of elements they can contain.
Human understanding of diagrams is constrained by the limits of human cognitive capabilities, such as short-term memory. Humans have limited cognitive resources. That is, they can attend to only so many things and perform only so many activities at once.

In this context, the problem is how to make diagrams that can be grasped easily.

The solution is to limit the number of elements in any given diagram to the magic number of seven, give or take two elements. These elements should be logically related; the diagram structure should express a sensible pattern connecting the diagram elements.

There's actually another pattern, at a different level, in this miniature pattern language. One level up from that of building diagrams is building models. Although many of the same forces are present at this level, the specific problem of how to make models that work adds a few others that have to be resolved. Look at the pattern called Digestible Chunks as one solution to this problem.

The context this time is building models (as opposed to diagrams). Within this context, most of the forces will look familiar:

A model must be comprehensive but focused.
The real world can be complex, messy, and unfocused.
Models have to communicate useful views of the real world.
Human understanding of diagrams and models is constrained by the limits of human cognitive capabilities, such as short-term memory.
Models are made up of one or more connected diagrams that have to be organized.
Human ability to organize models is also constrained by the limits of human cognitive capabilities.

The significant difference is that I've added organizing needs to our list.

The solution is to chunk the models into diagrams that are digestible bits, which are individually meaningful and connected in a sensible fashion. A related pattern useful for figuring out how to build these digestible bits is, of course, Seven Plus or Minus Two.

Naturally, there are other patterns that I could define that solve problems related to modeling software, and later on I will present some of these that are more specific to modeling with the UML. However, these two patterns illustrate not just the basic elements of a pattern, but also some of the distinctive and necessary characteristics of patterns.