There are so many different definitions and opinions around on what design patterns are and all seem to be (more or less) different. Sadly, most of them lead to a wrong view on design patterns that put them in a bad light. In fact there is a very precise definition what a design pattern is and what it isn't. I'd like to summarize this here:
What exactly is a design pattern?
A design pattern is a precise description of a best practice, or a written down collective experience of multiple developers. There is a certain rule that defines when a design pattern can claim itself as one: The rule of three.
The rule of three says that a pattern has to be used in at least three independent systems. In the best case by developers that have never talked to each other before.
A design pattern can never be invented! It is found or identified. If a single programmer describes his own best practices on how to solve a problem, then this is very nice of her, but it is not a design pattern. Even though it is written in a structure commonly known from the Gang-of-Four design patterns (the structure alone does not make a good design pattern).
Design patterns commonly are written in a so-called template (a predefined structure), which has to be proven over years to be able to precisley transport the content and the pattern's idea. The structure is not fixed and can vary from pattern to pattern. There are only three sections that must be present in every design pattern:
- Context: Definition of exactly when and in what circumstances the pattern can be used.
- Problem: A precise description of the problem that has to be solved.
- Solution: Right, the precise description of the solution to the problem.
The keyword here is precise. It is difficult to write a design pattern! Therefore, there are many conferences around the world that are here to help each other to identify if something is really pattern and how to describe it. These conferences are commonly known as "PLoP" conferences. There, people meet in so-called writers workshops and intensively discuss the text of patterns from different viewpoints. A pattern that has succeeded this process can generally be accepted as of high quality (which does not mean that the software automatically results in high quality, just because you applied the pattern). If you want to get a feeling why it is so difficult to write a good pattern, I can recommend you this paper that explains how you can write a pattern for "a doorlock", a thing everybody is familiar with. When I read the pattern, I'm always amazed how many details have to be taken into account to make this pattern work.
Design Patterns not only exist for software development. In fact, this concept has initially been developed for buildings architecture. Nowadays you can find patterns for software development, buildings architecture, cooking, education, organization in life, etc.
There are many more detailed aspects of a pattern, but these would go into too much detail for now. For example, when is a pattern a "classical" design pattern, or what is the difference between an architecture pattern, an architecture style, an idiom, etc.
What it is
- A description of a best practice of collective experience.
- A context-problem-solution construct that is very precise.
- A problem solution that has been discussed by many people (normally, experts in the field) and accepted as a viable solution.
- A way to document a best practice and hand it on to other struggling people.
What it is not
- A description of a best practice of a single person.
- Some kind of code structure, because patterns exist not only for software development.
- A pattern normally does not describe solutions that are obvious (it is important to note here that patterns can become obsolete, because especially in software development new or improved languages / frameworks can make the solution obvious).
I'm happy for your comments to improve this list.
Good books on design patterns
The famous Gang-of-Four object-oriented design patterns: Design Patterns: Elements of Reusable Object-Oriented Software; Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
Martin Fowler: Patterns of Enterprise Application Architecture
The complete POSA series: Starting with "Pattern-Oriented Software Architecture, Vol. 1: A System of Patterns"; Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal
Be careful when you buy books that have "design patterns" in its title. Many contain only solutions that someone thinks are design patterns, maybe even having a negative effect on the credibility of design patterns.
Further resources
Many software developers are mainly familiar with the patterns from the Gang-of-Four book, but in fact, there is a vast amount of patterns out there. You can search the conference websites, for example EuroPLoP, most of the patterns are freely available, or the library of the Hillside Group, an organization dedicated to the creation of design patterns.
Top comments (4)
This is a powerful idea I hadn't considered. Thanks for sharing!
That is what I tried to summarize in my article :-) (It is not an invention by me, it is a summarization of all the information I got from international design pattern conferences and books on this topic).
I'm not sure I can follow you here, could you please explain this (or redirect me to some resources I can read about it)? I'm not familiar with the connection of these specific programming languages and design patterns.
But these were no design patterns at the time of the development of these languages, were they? I'm only aware of message-passing design patterns, but they claimed to be design patterns only since the book "Enterprise Integration Patterns" and there the concepts of the languages you mentioned have already been applied in different other contexts.
The time is important, of course somebody has to "invent" the solution. But it can only become a design pattern if it has proven to be a solution to a problem in different systems.
So, the "design pattern" is not the original solution one came up with. The design pattern is the description of the solution, not the solution itself. And for a solution description to qualify as a design pattern, it must already exist.
It is the same with the original design patterns from Christopher Alexander. He did not invent the building constructs, it was just a collection of solution descriptions other architects have used in multiple times.
So to sum, of course, behind every design pattern stands a smart mind that initially came up with the solution. But then it was a great idea, not a design pattern yet :-).