The idea of design patterns is not new. Ever since there were engineers, design patterns have existed. The architects of the great pyramids must have used design patterns to envision and eventually build one of the most durable testimonies to quality engineering.
So what are design patterns? Simply put, design patterns name and describe effective solutions for common design problems. The name of a pattern gives us a common term that may be used when discussing design solutions. The description provides a guideline or template that can be applied to a frequently occurring design problem.
As software developers, why should we care about common terminologies for design solutions? Consider a project that's on a tight deadline (is there any such thing as a project that's not on a tight deadline?). When a pattern name is mentioned in a meeting of developers, and the attendees understand the meaning of that pattern, they can usually arrive at a design solution faster because they are all using the same terminology. Because the team is using a common vocabulary, they will probably spend less time discussing the ramifications of the proposed solution. If there is less time spent in "design churn", the team will have a greater chance of meeting their objectives.
To illustrate how useful a common vocabulary can be, imagine that you are on a team of civil engineers who are building a highway. If the terms cloverleaf, suspension bridge, or tunnel are used, you'll probably be able to picture in your mind a solution to a common transportation problem. These three terms are examples of names for design patterns. In this case the problem domain is civil engineering.
Design patterns do not provide specific and concrete recipes that should be followed each and every time. Instead, they identify elements, how they work together (i.e. collaborate), and the relationships that exist between each element in the design solution. The solutions suggested by a given pattern should be thought of as guidelines rather than rules. When it comes to object-oriented software design, the elements addressed in the patterns are typically described as classes.
One common mistake made by fledgling architects is to jump at the first solution for a given design problem. Unfortunately, if the architect does not consider the consequences of his or her decision, they may find that their hastiness results in a system that is less scalable, fault-tolerant, responsive, or maintainable than they had wished. Fortunately, the body of knowledge that usually accompanies a named design pattern oftentimes includes observations that provide insight into the pros and cons of using the particular design approach. If an architect is aware of the trade-offs involved in a design decision, he or she has a better chance of making the right choice for the problem at hand.
To summarize, all design patterns have the following characteristics …
As software developers and architects, why should we care about design patterns?
If we study design patterns and understand when they should be applied, we can build better products, and in the process bring benefit to our respective companies, our projects, our teams, and ourselves as well. Rather than reinventing the wheel, we can learn from our predecessors, and that's the key to building better software!
The concept of design patterns, as it pertains to software engineering, really got rolling with a quartet of engineers affectionately known as the "Gang of Four" (GO4). In 1995, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published their now famous book titled "Design Patterns, Elements of Reusable Object-Oriented Software".
This book began as an idea for a Ph.D. thesis by Erich Gamma in 1991. By 1992, Helm, Vlissides, and Johnson were all on-board. They summarized and submitted a catalogue of object-oriented software design patterns to the European Conference of Object-Oriented Programming (ECOOP) in 1993. The rest is history.
The GO4 gives credit to several people for the idea of design patterns. The GO4 first cites a civil engineer and architect named Christopher Alexander who published a paper in 1977 titled "A Pattern Language". In this treatise, Alexander sought to define step-by-step rules for solving common engineering problems relevant to the creation of buildings and communities.
The GO4 also looked to the works of such luminaries as Donald Knuth (The Art of Computer Programming, 1973), and James Coplien (Advanced C++: Programming Styles and Idioms 1992). In contrast to what the GO4 wrote about, these publications focused on lower-level software algorithms. The GO4 were also influenced by the writings of contemporaries such as Kent Beck (The Smalltalk Report, 1993), and Peter Coad (Object-Oriented Patterns, Communications of the ACM, September 1992).
While the GO4 were not the originators of the concept, they are widely praised for doing a great job of cataloguing software design patterns and bringing these concepts into the mainstream. They managed to observe what others were doing in the field, sort it all out, codify what they saw, and produce a body of work that defines solutions for a large number of problems developers frequently encounter when they build software.
As you might guess, the catalogue of design patterns has not remained static. Many developers and organizations have contributed additional patterns to the software industry since the GO4 book was published. You can find information about these more recent patterns on the web, and hopefully in your local bookstore as well. Still, we look fondly back to the landmark work produced by the GO4.