Singleton Pattern   «Prev  Next»
Lesson 2The elements of a pattern
ObjectiveUnderstand how Design Patterns can solve Problems.

Elements of Design Pattern, Intent, Motivation, Applicability, Structure

Design patterns themselves follow a pattern (a "meta-pattern," if you will). Each pattern has:
The intent states the problem that the pattern addresses
  1. The intent states the problem that the pattern addresses
  2. The motivation is a scenario that illustrates the problem
  3. The applicability of a pattern describes the circumstances under which the pattern is appropriate; that is, when you should and shouldn't use it.
  4. The structure of a pattern is normally displayed as some sort of object or class diagram.
  5. The participants in the pattern are the classes and objects that comprise it. Each class or object also has a list of responsibilities.
  6. The collaborations describe how classes and objects outside the pattern interact with the pattern.
  7. Consequences are the results of choosing a pattern, both positive and negative
  8. The implementation of a pattern is a set of code that uses the pattern. It shows the details and tricks that are needed to make it work
  9. The known uses section of a design pattern describes some object-oriented systems where the pattern is found. This provides some practical real-world examples you can use to get a closer grasp of the pattern.
  10. Lists other design patterns that are closely related.

Programming by Contract

Encapsulation makes it possible to produce dramatically more reliable code than the traditional programming style in which every function was able to modify data fields. Once we ensure that all constructors of a class create only objects with valid state and that all mutator operations preserve the valid state, then we can never have invalid objects. No operation should waste a lot of time checking for invalid objects. Bertrand Meyer, the pioneering designer of the Eiffel language, uses the metaphor of a contract to describe these guarantees. This chapter explores the ideas surrounding the concepts of programming by contract.

Design Experience

We all know the value of design experience. How many times have you had the feeling that you have solved a problem before but not knowing exactly where or how? If you could remember the details of the previous problem and how you solved it, then you could reuse the experience instead of rediscovering it. However, we do not do a good job of recording experience in software design for others to use.
Each design pattern systematically names and evaluates an important and recurring design in object-oriented systems. Our goal is to capture design experience in a form that people can use effectively. To this end has documented some of the most important design patterns and presents them as a catalog.
Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help a designer get a design "right" faster.

The following discusses the elements of design patterns.

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.