Design patterns are commonly defined as time-tested solutions to recurring design problems. The term refers to both the description of a solution that you can read, and an instance of that solution as used to solve a particular problem. (I like the analogy of comparing design patterns to a class and an object instance of the class. Each is a different way to represent a thing.) Design patterns have their roots in the work of Christopher Alexander, a civil engineer who wrote about his experience in solving design issues as they related to buildings and towns. It occurred to Alexander that certain design constructs, when used time and time again, lead to the desired effect. He documented and published the wisdom and experience he gained so that others could benefit. About 15 years ago, software professionals began to incorporate Alexander's principles into the creation of early design pattern documentation as a guide to novice developers. This early work led others to also write about design patterns and culminated in the publication of Design Patterns: Elements of Reusable Object-Oriented Software in 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. This book is considered to be the "coming out" of design patterns to the software community at large and has been influential in the evolution of design patterns since. Design Patterns described 23 patterns that were based on the experience of the authors at that time. These patterns were selected because they represented solutions to common problems in software development. Many more patterns have been documented and cataloged since the publishing of Design Patterns. However, these 23 are probably the best known and certainly the most popular.

Design patterns are represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. To illustrate a design pattern, consider the Adapter pattern, one of the original 23 patterns described in Design Patterns. Adapter provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are incompatible. To implement an Adapter, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.

Structure of a Design Pattern The design pattern community is growing both in membership and coverage. The pattern literature describes new patterns that solve emerging issues related to technical advancements. As a software professional, you are the beneficiary of this body of knowledge. To use these patterns, you will need to learn them and become familiar with them so you will know which pattern to pull from your toolbox when a design issue arises. Many patterns have been documented over the years. They have been classified in different ways by different authors. Take the time to learn different ways to classify design patterns because you will gain greater insight into them. As you learn more and more patterns, it would be a good idea to develop your own classification system; one reflecting the way you utilize them.

Design pattern documentation is highly structured. The patterns are documented from a template that identifies the information needed to understand the software problem and the solution in terms of the relationships between the classes and objects necessary to implement the solution. There is no uniform agreement within the design pattern community on how to describe a pattern template. Different authors prefer different styles for their pattern templates. Some authors prefer to be more expressive and less structured, while others prefer their pattern templates to be more precise and high grain in structure. We will use the template first described by the authors of Design Patterns to illustrate a template.