About Design Patterns

Patterns are general solutions to common problems, especially in architecture
and computer science where the term normally refers to this restricted sense.

Hence the word "pattern" here has a more specialised meaning than normal, being
a kind of procedure, algorithm, or way of doing things that's extracted from
one example problem domain where it's been deployed successfully so that it can
be used in others.

This sense of the term originates from Christopher Alexander's seminal Pattern
Language book, and originally applied to architectural patterns, but the term
has been taken up by computer scientists since it translates especially well to
that field.

For more information on the general meaning, see Wikipedia: 

* http://en.wikipedia.org/wiki/Design_pattern_%28architecture%29
* http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
* http://en.wikipedia.org/wiki/Pattern_language

Why Are Patterns Important?

* They cut redundancy.
* They aid us in tasks.
* They're interesting of themselves.

As John Keats said in =>a letter [1] to George and Georgina Keats in September
1819, "The only means of strengthening one's intellect is to make up one's mind
about nothing -- to let the mind be a thoroughfare for all thoughts." To
paraphrase a motto of Thomas Nashe, patterns impel patterns.

[1] http://englishhistory.net/keats/letters/georgekeatsseptember1819.html

Are Patterns Themselves Patterns?

In RDF Schema, the concept of Class is an instance of itself. In a similar way,
I think that the concept of a pattern is itself a pattern. To be a pattern, one
must recognize some abstract quality and be able to deploy it elsewhere. That
recognition, the general act of being able to see an abstract quality about
something, is itself an abstract thing, and can be deployed elsewhere: witness
the fact that patterns were first used in architecture but then found a nice
home in computer science.

Why Document Patterns?

I really enjoy reading about patterns, especially on the Portland Pattern
Repository wiki, the original c2.com wiki, so why not produce my own so that
others may enjoy them? Indeed, so that I may enjoy them: it's easy to forget
patterns once you initially learn them, and even if not there's always some
nuance or aspect of the thing that you can lose over time. Documenting prevents
that, as the documentation of things always has. It's what we call history.