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.

Using right

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 .

Related .

Design pattern is the term used to describe a solution to a problem that occurs frequently and also a way to summarize the idea of a code implementation, rather than describing the code you speak only, I am using a strategy. They are also applied to address some shortcomings of the language used.

A design pattern has several sessions that are important to know whether or not it should be adopted as

Scenario : Where the solution applies and why.

Advantages : Because this approach solves the problem elegantly.

Disadvantages : In which cases the solution does not apply or end up making your project more complex, as usually several new classes added to the project, working together to solve the problem. p>

Class / Organization Diagram : Shows the class structure of the pattern and how it relates.

Implementation : It's the code itself, the implementation can vary widely from one language to another, remember the pattern is just an idea of how to solve the problem a silver bullet.

Design Patterns

Although specific, corporate systems have several similar features. Consequently, many problems recur in different contexts.

Suppose that a particular problem will occur in two hundred different systems. In each system, this problem can be solved in a different way. So overall, we would have two hundred solutions to the same problem. Some solutions would probably be better than others or even one of them better than all the others.

From this comes the concept of design pattern or design pattern . A design pattern is a consolidated solution to a recurring problem in the development and maintenance of object-oriented software.

GoF Standards

The patterns defined in the Design Patterns: Elements of Reusable Object-Oriented Software are called GoF standards. They are categorized into three categories: design , structural and behavioral

Source:
K51 - Design Patterns in Java

Recommended Reading Source Making - Design Patterns
WebPro - Programming Principles

A design pattern is a general solution to solving a problem that often occurs in a software development / design context.

The biggest reference I know about design pattern is Design Patterns: Elements of Reusable Object-Oriented Software. The four authors are known as the Gang of Four, because the book is a catalog of the 23 best-known design patterns.

• Creation Patterns - They abstract the instantiation process, make a system independent of how objects are created, composed, and represented
• Structural Standards. They are those that deal with the composition of classes (or objects) to form large structures in the system;
• Behavioral Patterns. They characterize how classes (or objects) interact and distribute responsibility;

What are the existing standards?

• Structural Patterns: Adapter, Bridge, Composite, Decorator, Facade, Flyweight and Proxy;

• Behavior Patterns: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method and Visitor

  

Later I will complete this answer.

/ p>

A more concrete way of explaining this is: a Design Pattern is a particular combination of classes / interfaces that together solve a type of problem that is common in software development.

Examples:

• The pattern Observer , whose class diagram is so , solves the problem of notifying other classes that an event happened.
• The pattern Iterator , which has this class diagram, solves the problem of traversing elements stored in a container object (a list, set, dictionary, etc.) in a way that does not depend on how container is implemented.
• Singleton pattern prevents a class from being instantiated more than once.

These solutions are generally elegant and provide good maintainability, that is, they make the software well-prepared to accept changes at that point in the system where pattern has been applied.

It has become interesting to catalog these combinations for people to know, and if they run into a problem of the same type, use the pattern rather than reinventing the wheel with solutions that can often have low maintainability.

However, you have to take care to choose the right pattern to solve the problem, if the best solution is a pattern .

When the person encounters a situation and thinks "maybe the X pattern applies here" , he needs to carefully evaluate whether the pattern really applies to that situation, using his / her knowledge about the pattern (scope, intent, etc.) and trying to compare the problem he is facing with the type of problem that pattern / p>

A badly applied pattern can increase software complexity unnecessarily.

In summary, Design Pattern is a set of best practices that should be followed when developing software. This set aims to establish code patterns, test routines, and other artifacts necessary for the complete development cycle. This cycle is basically composed of: survey, analysis, development, testing, approval with key user and support.

In addition, a good Design Pattern is important for maintainability. This is because after development, the support team needs to be ahead of what has been developed. If you need to change or expand the software in the future, this transition can be made more smoothly.

Still on Design Pattern, it can be considered as the backbone of the software, it is the moment where it is necessary to think more and do less. And why this? Because the better the Design Pattern, the less rework you'll get. Note that I talked about all the steps that involve a Design Pattern and not just its development itself. Unfortunately many companies think differently. They prefer to do more and think less. Besides that, our area is undervalued. So it is common to pay less for people who are not interested in the Design Pattern theme. Whoever wants to be a real programmer needs to study and stay up to date on best practices.

We have numerous book authors (most in English) who cite the subject. I will cite only one that you consider to be one of the best: link