See also: http://www.st.se/Patterns/dokument/Microsoft%20PowerPoint%20-%20PatternsIntro.pdf.
Patterns are a way to analyze solutions to recurring problems, make them reusable and communicate them. Patterns are a way of thinking. Patterns are also a cult.
To generalize a solution to a problem, you have to look at the problem in its context: What are the (conflicting) goals, the forces, that recur in that context?
Describe the problem and its context, add an elegant solution that resolves the forces (that is, brings them into a dynamic balance), give the whole thing a name, and there you are - you have a pattern!
Because they turn out to be unbelievably useful, patterns have sprung up in a variety of fields: First in Architecture (buildings, not software!), then in Software Development, and now everywhere. :-) Although in mathematics the notion of generic grammars has been known for centuries to describe solutions to problems, the general public has no understanding of the math language. Patterns as defined by the originator ChristopherAlexander are much more readable and are a textual description of the core of a solution to a generic problem.
A variety of pattern categories are recognized in software pattern community. DesignPatterns are the most well known, but there are also ArchitecturePatterns?, AnalysisPatterns, OrganizationalPatterns and ProgrammingPatterns? (also called Idioms). Finally, there are AntiPatterns, patterns where the solution looks attractive, but actually creates more problems than it solves.
The most successful pattern book, and possibly the first one to buy (after browsing Wiki, of course), is DesignPatterns by the GangOfFour (ISBN 0201633612 ). It is also worth reading the original architecture book, TheTimelessWayOfBuilding by ChristopherAlexander. This book is very good for understanding the need for patterns and differentiating between good and bad patterns that occur in a system. Even though the book is about architecture of real buildings, its comments and text seem to relate so much to software engineering, with statements like "the minute an idea for a project is conceived, it's already too late to think of it from scratch!".
The required introductory material should be a little less academic in tone than the GoF book, I think. I've seen books on design patterns which appeared to have obfuscation as their primary goal. This is, in part, why I am coming so late to the party.
-- SteveHolden
This page mirrored in WikiPagesAboutWhatArePatterns as of April 29, 2006