I’m pretty sure that the first contact most software developers at large have with patterns is through the well known book "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson  and John Vlissides – the "Gang of Four" (GoF) as they became known. This book – containing twenty-four object oriented design level patterns – is just one of many books on the subject, and the twenty-four patterns it describes are just a small number of the documented patterns that are out there. Further, the patterns it describes are all pitched at the level of object oriented design, whereas there are many patterns documented at all stages and levels of software development: for example, see "Pattern-oriented Software Architecture Volume 1: A System of Patterns" by Frank Buschmann, Regine Meunier, Hans Rohnert, and Peter Sommerlad, which looks at patterns for system architecture, design patterns and programming idioms.

In order to start off the Software Patterns category, I thought I’d write a short introduction to the topic. In it, I aim to give an "in a nutshell" explanation of both what a pattern is, and what patterns contribute to software development.

What is a Pattern?

A pattern is basically a capturing of a problem (in context) together with a solution to that problem. As so often happens, though, things are just not that simple. To understand what a pattern is, I think it is worth stepping back and looking more generally at problems and their solutions. With this in mind, consider the following:

• There is very rarely any such thing as the solution to a problem. That is to say, any problem will usually have more than one solution, each solution offering its own set of tradeoffs. Finding a solution is not a matter of finding the right solution, rather it is a case of deciding on the most acceptable set of tradeoffs.
• Deploying a solution to a problem entails risk. If the solution turns out to be the wrong one, resources have been wasted. This risk can be mitigated by understanding the tradeoffs a solution offers, and the tradeoffs are best understood by drawing on the available experience.

The purpose of capturing a solution as a pattern is to help users choose the solution that will work best in their particular situation. Therefore, the most useful patterns are those harvested from existing practice/experience.

A pattern is made up – be it explicitly or implicitly – of the following elements:

1. Name. The name by which the pattern is known. This may also give alternative names, if there are any
2. Context. Problems occurs in context, and the context influences the suitability of a solution
3. Problem. Self explanatory. This is usually quite a short statement, and a popular choice is to phrase it as a short question
4. Forces. Factors that limit the choice of solution. The term forces is a metaphor from physics (forces influence the direction of the solution)
5. Solution. Self explanatory
6. Consequences. The pros and cons associated with the choice of solution. Sometimes the more general term Resulting Context (emphasising that the solution/consequences have changed the context from that in which the problem occurred) is used instead of consequences

These are the essential elements, but they are non-limiting in that they may be supported with other material. In particular, a pattern write-up often begins with an abstract or overview of the pattern, and of course examples are always good to include. Also, very importantly, examples of known uses should be included.

Example Pattern

• Name: Proxy
• Context: An object oriented software development where access to an object (the Subject) is non-trivial, in that it is necessary to assert some control over such access, or intercept the access in some way. For example, we may need to insert code to write log entries when operations are invoked on the object
• Problem: How can control be asserted over access to the Subject?
• Forces: The control asserted must be transparent from the client code perspective
• Solution: Let client code address a representative of – that is, a Proxy for – the Subject. The client code addresses the Proxy, and the Proxy forwards requests to the Subject (as well as forwarding the Subject’s responses to the client). In order to address the transparency requirement, the Proxy object should have the same interface as its target object; ideally it should be possible to interchange the Subject and Proxy in the client code
• Consequences: The above solution implements the ability to transparently assert control over access to the Subject. However, this transparency also hides any extra work done to access the Subject from clients. Therefore, it must be kept in mind that their is potential for performance problems to subtly creep into the system

Notation

There are various approaches to writing up patterns. The above example is also an example of the most disciplined. However, this approach does suffer from being quite formal and not particularly accessible for the reader. This is probably why pattern authors generally have a leaning towards less formal notations. Two popular forms are:

• Simply stating the pattern as a problem/solution pair. In this case, usually the context and forces are rolled in with the problem, while the consequences are included in the solution
• Describing the pattern from the perspective of intent and motivation. This is the approach used in the popular GoF "Design Patterns" book alluded to above in the introduction

Finally

I think patterns are a very important tool in the software development toolbox. I also think that the tendency towards more relaxed notational styles is a good thing in general because it makes for easier and more accessible reading. However, the more relaxed styles make it easy to overlook a fundamental point: a pattern is motivated by the need to understand the solution to a problem, together with its consequences. This must be kept in mind, otherwise there is a risk of this particular tool loosing its value.