1) What is a software design pattern?
A design pattern is a solution to a general software problem within a particular context.
Context : A recurring set of situations where the pattern applies.
Problem : A system of forces (goals and constraints) that occur repeatedly in this
context.
Solution : A description of communicating objects and classes (collaboration) that
can be applied to resolve those forces.
Design patterns capture solutions that have evolved over time as developers strive for
greater flexibility in their software. Whereas class libraries are reusable source code, and
components are reusable packaged objects, patterns are generic, reusable design
descriptions that are customized to solve a specific problem. The study of design patterns
provides a common vocabulary for communication and documentation, and it provides a
framework for evolution and improvement of existing patterns.
2) Why is the study of patterns important?
As initial software designs are implemented and deployed, programmers often discover
improvements which make the designs more adaptable to change. Design patterns capture
solutions that have evolved over time as developers strive for greater flexibility in their
software, and they document the solutions in a way which facilitates their reuse in other,
possibly unrelated systems. Design patterns allow us to reuse the knowledge of experienced
software designers.
Moreover, the study of design patterns provides a common vocabulary for communication
and documentation, and it provides a framework for evolution and improvement of existing
patterns. As an analogy, consider that during a discussion among programmers, the words
stack and tree can be used freely without explanation. Software developers understand
fundamental data structures such as a stack because these data structures are
welldocumented
in textbooks and are taught in computer science courses. The study of design
patterns will have a similar (but more profound) effect by allowing designers to say
composite pattern or observer pattern in a particular design context, without having to
describe all classes, relationships, and collaborations which make up the pattern. Patterns
raise the level of abstraction when discussing and documenting software designs.
3) How do I document a design pattern?
A pattern description must address the following major points:
Pattern Name and Classification : A short, meaningful name for the pattern,
usually only one or two words. Names provide a vocabulary for patterns, and they
have implied semantics choose names carefully. Following the GoF book, we can
also group patterns into higher level classifications such as creational, structural,
and behavioral patterns.
Problem : A general description of the problem context and the goals and
constraints that occur repeatedly in that context. A concrete motivational scenario
can be used to help describe the problem. The problem description should provide
guidance to assist others in recognizing situations where the pattern can be applied.
Solution : The classes and/or objects that participate in the design pattern, their
structure (e.g., in terms of a UML class diagram), their responsibilities, and their
collaborations. The solution provides an abstract description that can be applied in
many different situations. Sample Code in an object-oriented language can be used
to illustrate a concrete realization of the pattern.
Consequences : A discussion of the results and tradeoffs of applying the pattern.
Variations and language-dependent alternatives should also be addressed.
Known Uses : Examples of the pattern in real systems. Look for applications of the
pattern in language libraries and frameworks, published system descriptions, text
books, etc. Not every good solution represents a pattern. A general rule of thumb is
that a candidate pattern (also called a proto-pattern) should be discovered in a
minimum of three existing systems before it can rightfully be called a pattern.
The following quote by Robert Martin highlights the importance of providing pattern
descriptions: The revolutionary concept of the GoF book is not the fact that there are
patterns; it is the way in which those patterns are documented. ... Prior to the GoF book,
the only good way to learn patterns was to discover them in design documentation, or
(more probably) code.
