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.
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 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.
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.
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.
[GAMMA] Gamma, E. et al. Design Patterns Addison Wesley, 1995
[FOWLER] Fowler, Martin Analysis Patterns Addison Wesley, 1997