I’ve been looking into design pattern relationships until recently and didn’t realise that there has been work done in this area in the past. I find it awkward sometimes to understand how patterns relate to other patterns and which ones should be used in certain scenarios. Judging by the community I guess I’m not on my own. I recently found out that there are various classifications of patterns, not just the arrangement of patterns laid out originally by the Gang Of Four (which I don’t find that useful to be honest) in terms of their scope and purpose:

1. Zimmer (1995) suggested a set of horizontal layers to divide the patterns and proposes some new patterns which encompass sets of patterns. An example of this is the Objectifier pattern which encompasses the Strategy, Builder, Command and Visitor patterns. In order to relate the patterns Zimmer proposes a set of relations (X uses Y in solution, X is similar to Y, X can be combined with Y). This provides a new way of working with patterns since a developer can find out which patterns can be used together and which patterns achieve the same goal.

2. Noble (1998) discussed three new primary relationships for patterns, a pattern uses, refines and conflicts with another pattern. He also describes a series of secondary relationships with a pattern being a variant of another pattern, two patterns being similar or two patterns combining to solve a problem. Noble also describes sequences of elaboration which refers to a sequence of patterns beginning with small simple patterns building up into large scale architectural patterns.

3. Tichy (1998) looked at categorizing a large number of software patterns from various sources based on their purpose. The patterns selected were general purpose patterns, i.e. patterns that can be used in many different systems irrespective of their domain. They proposed a number of different categories to contain the patterns based on the problem they solved. Some of these included decoupling, state handling, control, concurrency and distribution.

There are others, people may be familiar with the J2EE pattern blueprints that describe how each of the J2EE patterns relate to each other:

http://java.sun.com/blueprints/patterns/index.html

This is kind of interesting because it provides a big picture for us to focus on, a top level hierarchy of patterns and how they are arranged from the enterprise down.

Also one more note, most people think of patterns as being the Gang Of Four design patterns but there are loads of other pattern types as well:

Antipatterns [Brown98];
Enterprise Architecture Patterns [Fowler02];
Elementary Patterns [Wallingford98];
Concurrency Patterns [Schmidt06];
Analysis Patterns [Fowler96];
Micropatterns [Gil95];
Re-engineering Patterns;
Process Patterns

etc… etc…