How to choose a Design Pattern?

History 

In order to understand what design patterns are, we first need to go back in time to the beginning of the history of the methods of construction projects. Who created design patterns and where did they come from?

Our journey began in 1977 when this theme was first mentioned in a book, A Pattern Language,  written by Christopher Alexander, Murray Silverstein, and Sara Ishikawa.

Christopher Alexander was an Austrian architect, mathematician, and urban planner. He was a Professor Emeritus at the University of California at Berkeley and was one of the critics of modern architecture, pointing out the social disintegration it caused.

Murray Silverstein is one of the coauthors of A Pattern Language and The Oregon Experiment, he taught architecture courses at the University of California, and later taught at the University of Washington. He has also written several articles on pattern languages.

Sara Ishikawa is an architect and scholar, specializing in people-space relationships. She is a Professor Emeritus of the College of Environmental Design at the University of California, Berkeley, and the coauthor of the books,  A Pattern Language, The Oregon Experiment, and Houses Generated By Patterns.

Since then, a few dozen object-oriented design patterns have emerged. Soon enough, this author's approach became very popular in various fields of programming, so many of these patterns now exist outside object-oriented design.

What are they 

First, design patterns are community-created solutions that help us organize our projects so that we can work together as a team without worrying about whether the other developer will be able to understand what we are doing in the code.

Each design pattern is like a blueprint of a building project that you can customize in a way that adds more value to your project. There are several design patterns used throughout the community, however, we will address the two best-known:

Abstract Factory

The intention of this is to provide an interface for creating families of objects -related or dependent - without specifying their concrete classes. It is also known as Kit.

This pattern should be applied when you want to isolate the application from the concrete class implementation, which could be a specific component or framework in which the application would know only one interface. In this case, concrete implementation would be known only in runtime or compilation time.

Factory Method

The Factory Method, also known as the virtual constructor, makes it possible to defer object creation to subclasses. It defines an interface to create objects but lets the subclasses decide which class to instantiate.

This pattern is commonly used by software designers when there is a need to encapsulate the creation of a class in isolation from the knowledge of the concrete class of the client application through an interface. This need is commonly desired by those working in framework development, which uses abstract classes to define and maintain relationships between objects. 

How to classify

All design patterns are classified according to their complexity, difficulty, and level of applicability, but basically, we can classify them into 2 main groups:

Idiomatic, are the lowest-level design patterns applied to a programming language;

Architectural patterns, are high-level patterns, that can be implemented in any programming language, and can also be used to design the architecture of the entire application.

How to categorize

In addition, all patterns can be categorized by their purpose or intent.

• Creative patterns provide mechanisms for creating objects that increase flexibility and code reuse;

• Structural patterns explain how to assemble objects and classes into larger structures, while still keeping the structures flexible and efficient;

• Behavioral patterns take care of efficient communication and the signaling of responsibilities between objects.

Benefits 

Besides everything we have described so far in the article, we also have some benefits when using design patterns in your applications. Some of those are: 

• Provide solutions that have already been tested and approved; 

• Makes the system easier to understand and maintain;

• Makes it easier for new devs to join the project;

• Reduces the project understanding curve;

• Facilitates the development of new modules;

• Improves communication between the project developers.

Conclusion

There is an analogy that can be made between design patterns and a game of chess: first, you have to learn the rules of the game, and only then do you start playing. Learning how to make the right moves is a process that takes time. 

But more important than knowing some good moves, it is understanding how the game works, and what leads the player to make each move. Basically, more important than knowing how to implement some design pattern, first, you need to know how it works.

The main cause of failure in the application of patterns is the lack of knowledge of their real purpose.