Writing Software Patterns

Martin Fowler

What is a Pattern?

A common definition of a pattern is that it is a solution to a problem in a context. That’s a definition that’s always struck me as being rather unhelpful. For me, a pattern is primarily a way to chunk up advice about a topic. Chunking is important because there’s such a huge amount of knowledge you need to write software. As a result there needs be ways to divide knowledge up so you don’t need to remember it all - what you need is to be able to get at a particular chunk of knowledge when you need it. Only then do you need details.

The solution provides a useful focus for the chunking. With some young eager programmer asking some grizzly veteran (i.e. anyone over thirty) how to deal with a particular situation and hear the veteran say “oh - you’ll need an identity map there”. The colleague can then look up identity map in some suitable patterns book.

So to make this chunking work each pattern should name a solution. This solution should be concrete, at least at the level of discussion we are talking about. You should be able to go away and use the pattern once you’re given the reference. If you’re successful the name should enter the vocabulary of the profession. It can take a while to do this, but when you say ‘decorator’ any reasonable professional should know what you mean.

Patterns should have recurrence, which means the solution must be applicable in lots of different situations. If you are talking about something that’s a one-off, then it’s not adding the name to the profession’s vocabulary.

One of the interesting things here is that a singular solution can often lead to a recurrent pattern. This usually crops up when you see two different singular solutions which look completely different on the surface, yet have a deeper similarity - what Christopher Alexander* refers to as the “core of the solution”. Let me give an example for this. I was looking at one of our early Java web projects. On this project the team wasn’t allowed to use JSPs. So they wrote a set of Java classes which walked through a structure of domain objects, and produced the appropriate HTML for a particular domain object. They noticed they were getting duplication in the code for spitting out common HTML structures for fields, tables, etc. So they pulled all of the HTML spitting code out into a second utility class that had methods like renderField (String label). When they did this they noticed that they could make drastic changes to the entire web application’s appearance just by altering code in the utility class.

Later on I saw a different project. They were using XSLT to turn XML into HTML pages, much as I do on this site. But they needed to support multiple organizations who wanted the same data displayed in their own format. So they split the transformation into two steps, first producing an intermediate XML with elements like field and table, with the second stage actually producing the HTML. They would have a different second stage for each organization.

Although it seems obvious as I write it now, when I first saw these two projects I sensed there was something similar in their approaches. However, it took me several months to understand the key point - splitting a transformation into two steps: logical page and physical (HTML) page. This is the “core of the solution” which I wrote up as Two Step View. One of the great intellectual challenges of patterns is finding and isolating this core amongst all the surrounding stuff that’s needed on real projects.

Patterns versus Recipes

A popular, and very effective, form of technical writing is the cookbook style (eg The Perl Cookbook, Rails Recipes). There is a lot of similarity between cookbooks and patterns books. Both emphasize a problem-solution style.

I see the big difference between the two in the notion of building a vocabulary. Recipes tend to be more particular, usually tied to a particular programming language and platform. Even when patterns are tied to a platform, they try to describe more general concepts.

As a consequence of this recipes have a stronger problem focus than the solution focus in patterns.

Although my writing interest is in patterns, this reflects my interest in general design principles rather than a judgment on the relative usefulness of the two styles. Both are effective for same basic reason - they chunk based on a concrete thing somebody wants to get done today. As a result I find both very effective. You can also learn great principles from them, but it’s the answers to particular questions that bring you to the table.

Why are Patterns important?

One of the quotes that I find particularly appealing when I think about the need for patterns that that part of interest in patterns came from “...observations that projects fail despite the latest technology for lack of ordinary solutions”[PLoPD 1]. Patterns provide a way to organize and name those ordinary solutions to make it easier for people to use them.

Since these solutions are ordinary, it’s common that experts in a field won’t find anything new in a patterns book. For such people the biggest value of a patterns book is to help them to pass on the solutions to their colleagues.

Despite my liking for patterns, I don’t think that patterns are the right approach for all situations. Even in my own latest patterns book, I used a mixture of patterns and narrative text. I think the patterns helped focus the narrative and provided a good way for me to separate the details of the solutions from the overview discussion of them. Patterns are a communication medium, and like any communication technique there are situations where they work well and those where they work badly. Practice and familiarity help you tell the difference.