A Design Pattern is a solution to a reoccurring problem in a context. The study of design patterns can help advance the technical expertise of you or your design team. Software design patters serve us as examples of good design in practice. We can learn good design form the experience of others. This idea is very easy to understand. Imagine that you're doing something around your house, you encounter a problem, and you solve it. You're so excited about your clever solution that you run next door and tell your neighbor what you did. The same problem comes up in your neighbor's house and now he knows how to solve it. He's so thrilled that he tells his brother-in-law, and guess what - a month later his brother-in-law uses the same solution to solve the problem when he experiences it in his house. A Pattern was born.
Notice the reoccurring aspect. There is a saying (joke?) in the patterns community that when you solve the first problem, it's just an accident; when you solve the second problem it's a coincidence; but when you use the same solution the third time, now you have a pattern.
Design Patterns started their rise to popularity when the book, "Design Patterns - Elements of Reusable Object-Oriented Software," by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, was published in 1995. The book won such widespread acceptance by the software engineering community that the four authors quickly became known as the Gang Of Four, and GoF (Gang of Four) became a new TLA (Three Letter Acronym). The book is a catalog of twenty three patterns and can be viewed as the start of the patterns movement. The Pattern Languages of Program Design (PlopD) were held each year and provided an opportunity for people to present more patterns.
When people first encounter Design Patterns, often by reading the GoF book, their reactions seem to fall into three groups, ranging from total bewilderment, to the feeling that they aren't learning anything they haven't used before, to anxiousness - hoping to soon encounter the problem so that they can apply the elegant solution that they just learned.
That feeling of bewilderment, experienced by the first group, is usually due to an unfamiliarity with the problem that is being solved. The Design Patterns book describes the problem in the context of some system, and if you can't relate to this system, you may not understand the problem well enough to appreciate the solution. In our Design Patterns course, we address this problem by demonstrating the patterns in contexts different from those used in the GoF book.
The second group of people, typically seasoned software engineers, often just shrug their shoulders as they read about Design Patterns. An often heard remark is, "I've been doing that for years, I didn't know it had a name." That is an accurate statement. The Gang of Four didn't actually discover the Design Patterns in the sense that they formulated the solutions to the problems that the patterns solve. What they did was recognize the reoccurring aspect of the solutions and found a way to document and catalog the patterns. Just like other engineering disciplines, software engineering now has a handbook of solutions to common problems.
This notion of a handbook is truly revolutionary in software engineering. People are able to communicate better by referring to a piece of the architecture by the name of the pattern, i.e., the patterns form a common language that engineers on a project can use. A senior engineer might say to a new hire, "We used the Adapter Pattern here enabling us to use some of the legacy code in this new feature," and the new hire will recognize both the problem being solved as well as the solution, and immediately grasp an entire area of the architecture. It is like designs are now able to be articulated at another level.
The final group of newcomers to patterns is a bit troublesome. It is commendable that people take the initiative and learn about patterns. The only way to become a great software engineer is to study great software designs. Published design patterns are an excellent source of material because they are proven solutions, tweaked, perfected, used again and again, and reviewed. But a little bit of knowledge is a dangerous thing. When pattern newbies are enthused and anxious to use newly learned patterns in their current projects it is very easy to be lured into applying a pattern just to use the pattern, when there really wasn't a problem that needed to be solved. If patterns are not used judiciously, they can do more harm than good.
Every pattern has pros and cons. When a pattern is applied, it usually means additional classes and associations are introduced into the architecture, increasing its complexity. There is a tradeoff. Care must be taken to ensure that the cure (the pattern) isn't worse than the symptom (the problem). In our Design Patterns course, we make an effort to discuss the consequences of using each of the patterns that we cover and we continually stress that solutions shouldn't be applied unless there is a definite problem. Design patterns can't simply be copied out of the GoF book and inserted into the code for a project. Studying patterns provides a level of problem recognition and a general formulation of a solution. Each use is unique and the pattern must be adapted to the context in which it is being used.
Whether you read the books yourself, take our course, or hold a lunch-time study group, every software engineer should make the study of design patterns part of their ongoing education.