We usually see the design pattern as a cake recipe. It's a role model. It's a way of coding something to get a certain result, a certain solution. Usually these recipes were created by those who have had the problem, thought a lot about it and found a solution that could be universal.
Recipes focus on a very specific problem and probably idiomatic . DPs are more general and focus on the problem rather than the implementation.
Design patterns are ideas, not tools, technologies, products, methodologies, paradigms, etc.
There are some famous patterns that are very common in many applications. But nothing prevents you from setting your own standards for specific applications, if it can repeat itself in your work.
Some of these patterns are documented and examples are provided. Some may be more automated and a library or framework can be made available for ease of deployment and use.
Others are so common that they can be inserted into programming languages to make it even easier.
Patterns that have gained fame
When people think of design pattern it is common to think of the main ones, the defined by the Gang of Four . They also think of patterns like the MVC and the like. But they forget that everything is design pattern.
Standards are everywhere
High-level programming languages are all based on design patterns that were used when programming assembly in the early days of computing.
A variable is a design pattern for accessing a value at a given memory address. You will not read this on any list of patterns, after all it has become so common, so transparent, that no one else thinks of it as a pattern.
Language flow control constructs are patterns that decide and deviate the order of execution of the instructions.
Object-oriented programming is a paradigm composed of a set of design patterns. So even you can program OO without its own language for it .
Inheritance is a form of code reuse that takes advantage of an established pattern in another class.
When you use a dictionary, you are using an access pattern to a key and value data structure. When you do a quicksort , you are using a pattern.
It is a mistake to reduce the standards to these known, and even more, try to adapt all code to a standard. There are those who program "pattern oriented", and often commit atrocities in the code because of this. In fact the GoF came to disseminate the term, but also to misrepresent what it really is. Do not get carried away by the use of fashion. This limits the actual utility of it.
You have to know when to adopt it, when to adapt it and when to ignore it. Of course if you do not know all the best known, you run the risk of reinventing the wheel worse. But trying to use a standard where it does not fit, also brings disastrous results. You do not have to be looking for a pattern at all.
When you think of your application as always creating a new pattern, it may be easier to find out if one already exists that can be applied, or it may make it easier to clarify what you are doing. Reusable solutions are usually lighter.
Formalized patterns have a meaningful name, have an explanation, context, and example implementation.
In addition to GoF, there are other collections of patterns: A Pattern Language , Portland , Coplien , POSA and EAA .