The architect Christopher Alexander had created them in A Pattern Language (1977) as a method of formally documenting solutions to design problems. The idea is that if you're having to solve the same thing over and over again but in slightly different ways, if you give a name to the solution and document and understand it thoroughly (cf. SlogansAreEnough), you'll save much repetition of effort. At first I didn't know about this plan, but I still found them usable.
Is SlogansAreEnough really enough? Jeffarch observes that if you mention a design pattern often enough, you can probably reconstruct its meaning from context. A design pattern that rots away possibly wasn't worth it anyway; if you tried to make the topic prominent but it didn't make it, then perhaps its time wasn't right. Also, even if slogans aren't enough, they're better than nothing. In a way, the whole Design Pattern method relies on the AlwaysUsefulLayers pattern. Indeed, I came up with SlogansAreEnough and AlwaysUsefulLayers when reading the principles of Content-Rich Design, which are clearly sub-design patterns themselves. The whole design pattern system is kinda like adding hooks to fractal. Doesn't make it any less fractal, but it makes the best use of the structure within a particular context.
The Portland Pattern Respository says "[a] set of [design] patterns becomes a pattern language when each of its patterns, once solved, leads to more patterns that should then be considered". MJD says that "The pattern language does not tell you how to design anything; It helps you decide what should be designed", but I think that patterns can be about the how as well as the what. Patterns can be applied at, perhaps, many levels.
- CamelCase is good beacause single words give WikiDictionaryFallacy
- There are MetaDesignPatterns
- Topic prominent... all about documenting and structurising