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

Design patterns themselves follow a pattern (a "meta-pattern," if you will). Each pattern has:

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.

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 gofpattern.com 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.

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.