Singleton Pattern   «Prev  Next»

Elements of Design Patterns

Intent A statement of the problem
Motivation A scenario that illustrates the problem
ApplicabilityDescribes the circumstances under which the pattern is appropriate
Structure An object or class diagram
Participants The classes and objects that comprise a pattern
Collaborations Describes how classes and objects outside the pattern interact with the pattern
Consequences The results of choosing a pattern, both positive and negative
Implementation A set of code that uses the pattern
Known uses Describes some object-oriented systems where the pattern is found
Related patterns Lists other design patterns that are affiliated

The Emergence of Design Patterns

Interest in patterns has fostered one of the fastest growing communities in contemporary software design. Like many emergent software techniques in recent history such as
  1. structured programming,
  2. data abstraction, and
  3. objects
they have captured the imagination of many in the industry. Most of these techniques fail to fulfill the expectations that propel them to such prominence, partly because immature ideas are exposed to the market prematurely. This is a recipe not only for mismatched expectations but for misinformation, which in turn fuels expectations.
Dialogue continues on what is and is not a pattern, on what is and is not a good pattern; this website does not cap that dialogue but contributes to it. The pattern community values diversity: there are many things called patterns that share a small core of techniques, principles, and values, all of which have proven useful to programmers. There are, in fact, several pattern communities, some of them quite decoupled from each other. This module attempts to capture the practice and foundations of the mainstream pattern culture.
When we discuss patterns in public, we bear responsibility for setting reasonable expectations for patterns. Most new techniques are heralded by expectations that outstrip what the technique can deliver, and the danger for patterns to fail into this trap is immense.
Design Patterns touch critical issues that are central to strategic software development, and they are important for that reason. But they are also just documentation, and rely on the insights of the people who create and use them. It is important to view patterns as one more tool in the designers tool kit. Their success depends on people, and particularly on the most human aspects of software development and its culture.
This website draws directly on the contributions of many pattern writers and pattern thinkers, which takes the material outside my immediate sphere of thought and into the realm of object technology. In fact, the following pages probably bear more of my colleagues words than my own; I provide the arrangement and the glue that tie the pieces together by means of object technology.
This is consistent with another important agenda of the pattern community: we would much rather read, use, and write patterns than talk or write about patterns. Premature abstraction is dangerous; it too easily distracts us from the ends to which we should be aspiring. So, although this briefing is an early attempt to abstract principles from the pattern community and explores the frontiers of its value system, it is grounded in real object technology. Focus on the patterns, think about them, and understand them, then read the surrounding analyses and commentary and expand your consciousness through the application of object technology.