• Writings of architect Christopher Alexander
  (coined this use of the term "pattern" ca. 1977-1979)

• Documentation of best practices and handbooks for engineering and architecture

• Literate programming (Don Knuth), ca. 1984

• Kent Beck and Ward Cunningham, Textronix, OOPSLA'87
  (used Alexander's "pattern" ideas for Smalltalk GUI design)

• Erich Gamma, Ph. D. thesis, 1988-1991

• James Coplien, Advanced C++ Idioms book, 1989-1991

• Gamma, Helm, Johnson, Vlissides ("Gang of Four")
  Object-Oriented Design Patterns book, 1991-1994

• PLoP Conferences and books, 1994-present

A "pattern" is ...

• An abstraction from a concrete form which keeps recurring in specific, non-arbitrary contexts. [generic definition]

• A recurring solution to a common problem in a given context and system of forces. [Alexander]

• A named "nugget" of instructive insight, conveying the essence of a proven solution to a recurring problem in a given context amidst competing concerns.

• A successfully recurring "best practice" that has proven itself in the "trenches".

• A literary format for capturing the wisdom and experience of expert designers, and communicating it to novices

• Design Patterns (software design; often object-oriented):
  • architecture (systems design)
  • design (component interactions)
  • programming idioms (language-specific techniques/style)

• Analysis Patterns (recurring & reusable analysis models)

• Organization Patterns (structure of organizations/projects)

• Process Patterns (software process design)

• Domain-specific - Any other domain you can think of!

Name

• A meaningful "conceptual handle" for discussion

Context

• Tells how the problem occurs / when the solution works

Problem

• Statement of the problem / intent of the solution

Forces

• Trade-offs, goals+constraints, motivating factors/concerns
• Tells why the problem is difficult

Solution

• Tells how to generate the solution
• The solution structure, its participants & collaborations

Examples (optional)

Resulting Context

• Describes the end result, benefits and consequences
• Shows how the forces were balanced/traded-off
• Tells how the solution works out

Rationale (optional)

• Underlying principles/heuristics justifying the solution
• Tells underpinnings of why the solution works out

Related Patterns

• Patterns which are similar, or which may precede/follow this one

Known Uses

• 3 or more independent instances of "real world" success

Software Patterns help us because they:

• Solve "real world" problems

• Capture domain expertise

• Document design decisions and rationale

• Reuse wisdom and experience of master practitioners

• Convey expert insight to novices

• Form a shared vocabulary for problem-solving discussion

• Show more than just the solution:
  • context (when and where)
  • forces (trade-off alternatives, misfits, goals+constraints)
  • resolution (how and why the solution balances the forces)

Software Patterns are not ...

• Restricted to software design or Object-Oriented design

• Untested ideas/theories or new inventions

• Solutions that have worked only once

• Any old thing written-up in pattern format

• Abstract principles or heuristics

• Universally applicable for all contexts

• A "silver bullet" or panacea

Software Patterns are ...

• Recurring solutions to common problems of design

• Practical/concrete solutions to real world problems

• Context specific

• "Best-fits" for the given set of concerns/trade-offs

• "Old hat" to seasoned professionals and domain experts

• A literary form for documenting best practices

• A shared vocabulary for problem-solving discussions

• An effective means of (re)using, sharing, and building upon existing wisdom/experience/expertise

• Massively hyped!

• A Pattern Language: Towns, Buildings, Construction (APL)
  Christopher Alexander; Oxford University Press, 1977

• The Timeless Way of Building (TTWoB)
  Christopher Alexander; Oxford University Press, 1979
  

• Design Patterns: Elements of Reusable Object-Oriented Software (GoF)
  Gamma, Helm, Johnson, Vlissides; Addison-Wesley, 1994
  

• Pattern-Oriented Software Architecture: A System of Patterns (POSA)
  Buschmann, Meunier, Rohnert, Sommerlad, Stal; Wiley and Sons, 1996

• Pattern Languages of Program Design (PLoPD1)
  Coplien and Schmidt (editors); Addison-Wesley, 1995

• Patterns of Software: Tales from the Software Community
  Richard Gabriel; Oxford University Press, 1996

• Analysis Patterns: Reusable Object Models
  Martin Fowler; Addison-Wesley, 1996

• Pattern Languages of Program Design 2 (PLoPD2)
  Vlissides, Coplien, and Kerth (editors); Addison-Wesley, 1996

• Pattern Languages of Program Design 3 (PLoPD2)
  Martin, Riehle, and Buschmann (editors); Addison-Wesley, 1997

• Object Models: Strategies, Patterns, & Applications
  Peter Coad with David North & Mark Mayfield; Prentice Hall, 1995

• Patterns Home Page, http://www.hillside.net/patterns/

• Patterns Discussion FAQ, http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html

• Ward Cunningham's WikiWikiWeb, http://c2.com/cgi/wiki?WelcomeVisitors

• Portland Pattern Repository, http://www.c2.com/pp/

• AGCS Patterns Page, http://www.agcs.com/patterns/

• Jim Coplien's OrganizationPatterns Front Page (a WikiWikiWeb work-alike), http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns

• Patterns Mailing Lists, http://www.hillside.net/patterns/Lists.html

• Cetus Links: Patterns, http://www.objenv.com/cetus/oo_patterns.html

• Brad's Pattern Links, http://www.bradapp.net/links/sw-pats.html

• Brad's Patterns Intro, http://www.bradapp.net/docs/patterns-intro.html

• Luke Hohmann's Patterns Intro, http://members.aol.com/lhohmann/papers.htm

• Doug Lea's OOD Patterns Intro, http://gee.cs.oswego.edu/dl/ca/ca/ca.html