According to Christopher Alexander, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."
I think the value of patterns is two key things:
1. Concise solution descriptions
2. A common vocabulary
I also think the best way to think about patterns is that they are a simple way to share strategies and principles. By naming them, you give them a simple handle.
Recently, a colleague asked me for a simple pattern template, and I didn’t have anything to just point to, so I did a quick roundup of some examples.
Here are example pattern schemas and pattern templates from a few key sources:
|Enterprise Solution Patterns||
|Patterns for Enterprise Solution Architecture||
|Real-Time Design Patterns||
|Web Services security Patterns||
|Windows Azure Design Patterns||
|Enterprise Solution Patterns||Three-layered Services Application|
|Web Services security Patterns||Trusted Subsystem Pattern|
|Windows Azure Design Patterns|
Pattlets were used in Enterprise Solution Patterns to briefly summarize a pattern, without fully documenting it. Here are a few samples:
|Abstract Factory||Provides an interface for creating families of dependent objects without specifying their concrete classes.|
|Application Controller||Is a centralized point for handing screen navigation and the flow of an application.|
|Facade||Provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.|
A page of pattlets is available on MSDN.