I’ve been talking to various people about pattern languages lately and trying to get various developers here at youDevise to give lightning talks about patterns to help spread knowledge about them a little. During all of this I’ve noticed a recurring theme: people usually think that a pattern is a description of an implementation. This means that people start using pattern language to talk about specific implementations to solve problems. I think this is wrong and leads to misunderstanding with no greater insight into the problem that is being solved.
Various communities have railed against patterns because of this focus on implementation (see Design Patterns in Dynamic Programming for one example) because many of the implementations are nonsensical in their environment. This is a perfectly reasonable reaction to a language that is being used solely to express a particular kind of solution to a general problem.
Instead of patterns being about solutions or implementations, I think that they should instead be seen as identification of problems. When you say you plan to use the Factory pattern, what you are really saying is that you have encountered a particular problem: you need to create instances of an object, but the concrete class of the object being created may change.
Once the pattern language has been turned around like this, then suddenly many more things start to fall into place. Patterns beg other patterns (the identification of one problem brings to light other problems that will need to be solved). Patterns have synonyms (Template Method and Strategy). The list goes on.
So try to change your thinking about pattern languages: instead of using them to express a concrete solution, make them a way of identifying the problem you are trying to solve. From there you can start choosing the best implementation based on your context.