Design Patterns
===============

Patterns are a relatively recent software engineering problem-solving
discipline that emerged from the object-oriented community.

Definition and History 
----------------------

The use of patterns is essentially the reuse of well-established good ideas.
A "pattern" is a named, well-understood, good solution to a common problem
in context.

The idea comes originally from the architect Chrisopher Alexander (70s),
who described and named common architectural problems and discussed solutions
to them. His actual definition was:

   Each pattern is a three-part rule, which expresses a relation between
   a certain context, a problem, and a solution. 

   As an element in the world, each pattern is a relationship between a
   certain context, a certain system of forces which occurs repeatedly
   in that context, and a certain spatial configuration which allows
   these forces to resolve themselves.

   As an element of language, a pattern is an instruction, which shows
   how this spatial configuration can be used, over and over again,
   to resolve the given system of forces, wherever the context makes
   it relevant.

In their now classic 95 book, Design Patterns -- Elements of Reusable
Object-oriented Software, the GoF (gang of four: Gamma, Helm, Johnson,
Vlissides) defines design patterns as "descriptions of communicating
objects and classes that are customized to solve a general design problem
in a particular context."  They go on to say ...

   A design pattern names, abstracts, and identifies the key aspects of a
   common design structure that make it useful for creating a reusable
   object-oriented design.  The design pattern identifies the participating
   classes and their instances, their roles and collaborations, and the
   distribution of responsibilities. 

   Each design pattern focuses on a particular object-oriented design problem
   or issue. It describes when it applies, whether or not in can be applied
   in view of other design constraints, and the consequences and trade-offs
   of its use. A design pattern also provides sample code to illustrate an
   implementation.  
   
   Although design patterns describe object-oriented designs, they are based
   on practical solutions that have been implemented in mainstream
   object-oriented programming languages. 

Examples
--------
Iterator -- Provide an object which traverses some aggregate structure,
abstracting away assumptions about the implementation of that structure. 

The simplest iterator has a "next element" method, which returns elements in
some sequential order until there are no more. More sophisticated iterators
might allow several directions and types of movement through a complex
structure. 

Singleton -- Ensure a class only has one instance, and provide a global
point of access to it. 

Often, a system only needs to create one instance of a class, and that
instance will be accessed throughout the program. Examples would include
objects needed for logging, communication, database access, etc. You could
pass such an instance from method to method, or assign it to each object
in the system. However, this adds a lot of unnecessary complexity. 

Builder -- Separate the construction of a complex object from its
representation so that the same construction process can create different
representations.