small medium large xlarge

Patterns and Piano Chords

What is a Pattern? A Pattern is a relatively
new idea in computer science. It attempts to document a solution
to a problem in a given context.
Patterns became popular with the
book Design Patterns, which is known as
the “Gang of Four” book (or GoF, for short). Various conferences
including PLoP have also sprung up to enrich the pattern landscape.

The GoF book describes 23 basic design patterns such as Proxy
and Visitor. These are widespread, basic patterns that
everyone uses—even if you aren’t aware of patterns. Martin Fowler’s
book Analysis Patterns describes a higher
level of patterns that model typical business processes you may
discover during requirements analysis.

A pattern is more than an idiom, which may be tied to a particular
programming language (as in Jim Coplien’s classic C++ Programming
Idioms
book, or various Smalltalk books), but less than a
full-fledged design document for any specific project.

Not a Template

A pattern is not a template—at least not in the sense of a
dressmaker’s template, or a woodworker’s pattern. You can’t simply
trace the pattern and cut it out for any project that might look
similar.

It is not a recipe. You can’t just add ingredients and stir
mindlessly to achieve a finished product.

So what is a pattern, then? Two good examples come to mind: let’s
look at chess games and piano players.

Chess Boards

World class chess players rarely examine the chess board piece by
piece. Instead, they visualize the entire state of the board as a
single entity, or a small number number of related entities.

Think of these groupings of chess pieces as patterns of
pieces. Expert chess players are able to recognize and manipulate the
chess board at this higher level of patterns of pieces. They don’t
see the individual pieces any more.

A pattern of pieces by itself, of course, isn’t very useful. The
relationship between that set of pieces and all others on the board is
still the focal point.

Piano Chords

Piano players work at a higher level of abstraction in the same
fashion. Rather than read a simple chord as the individual notes “F Bb
D”, experienced piano players will read a Bb chord in the second
inversion, and see the pattern as a particular hand position
using the first, third, and fifth fingers. This higher level of
abstraction really comes in handy when playing a more complex chord,
like an F#min13.

But just because you know what the basic pattern of a particular chord
looks like, you might not always choose to play it that way using the
same fingers. Depending on the chords that precede and follow it, you
may require different fingerings to hit the same notes. The pattern—the
shape of the chord—is still firmly in you mind, but how you
realize that pattern depends on the circumstances.

Studying Patterns

I see two main advantages to studying patterns.

First, we can use patterns in a similar manner to the chess and piano
players, to give us a common vocabulary for study and discussion at a
higher level than we could by discussing individual components and
their interrelationships.

This can be a great short cut among developers and architects to
discuss high-level solutions to problems without having to go into the
nitty-gritty detail.

However, some people expect to pick up the GoF book or one of the many other books on the topic and find instant solutions that they can
immediately apply to their project. If I’ve given that impression,
I’m sorry—it doesn’t work that way.

Reading a published pattern shouldn’t provide you with a solution, but
it should inspire a solution. Perhaps if you used this pattern
in combination with that other pattern, but changed it a little bit
and…

This is the second big advantage to studying patterns—inspiration.
Most developers do not have ten or more years or modeling or analysis
experience. But by reading a book like Fowler’s, you can see the sort
of techniques and approaches that he’s used in certain
circumstances—and how to combine various basic patterns into even
higher-level patterns.

No Magic

Unfortunately, many people in the industry try to hail every new
development as the next Silver Bullet—the thing that will make
programming easy and raise quality and productivity. The thing
that will let novice programmers jump in and churn out megabytes of
beautiful code.

Well, it ain’t gonna happen. Software development will never be easy.
No tool or technique, however sophisticated, will turn a novice into
an expert overnight. Patterns are not magic. They won’t rescue
either your project or your career. They are simply a good idea, a
way to discuss design issues in an abstract, and hopefully usable
manner.

We haven’t even figured out to index or organize them well! People
have widely differing opinions on how to even define a pattern; how
detailed or abstract should it be? What format should it be in? Some
advocate rigid sections for pattern, such as Problem, Context, Forces,
Solution, while others go for a more relaxed, informal approach.

And they are all correct. To me, the chief criteria for describing a
pattern is that it must be useful to the person reading it.
It should provide insight, or clarify something the reader has always
known or done but not really thought about. Above all, a pattern is a
tool for communication, for education both of the writer and the
reader.

That’s all. No magic. No silver bullet. You still have to
think, but hopefully we can start writing down some of the more interesting things we do to think about.

References

[GAMMA]
Gamma, E. et al. Design Patterns
Addison Wesley, 1995

[FOWLER]
Fowler, Martin Analysis Patterns
Addison Wesley, 1997