How could I miss a blog post explaining software design patterns! This article will list the basic design patterns that exist, so you can read and understand how they work. But also, I wanted to tell you a little about what these software design patterns are and how can they make your day-to-day life easier.
What are software design patterns?
Lets have one thing clear: however specific a problem you are facing during the development of your software, there is a 99% chance (a fully invented and tested solution already existes) that someone has faced A problem a similar in the past that it can be solved or modeled in the same way .
With modeling I am referring to the fact that the class structure that shapes the solution to your problem may already be invented, because you are solving a common problem that other people have already solved before.
If the way to solve that problem can be extracted, explained and reused in multiple scopes, then we are faced with software design patterns.
A software design pattern is a reusable way to solve a common problem. The concept of software design pattern has been around since the late 70s, but his true popularisation emerged in the 90s with the launch of the book Design Pattern by the Gang of Four, is the name with which the creators of this book are known: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. It explains 23 design patterns, which have since been a benchmark.
Why are design patterns useful?
It may seem silly, but if you do not find usefulness to things you will end up not using them. Design patterns are very useful for the following reasons:
1. Save you time
I know you’ll love finding an ingenious solution to a problem when you’re modeling your program, and it’s normal, it happens to me too. As I say, development is an almost artistic process, and that mental challenge entails reverts to enormous personal fulfillments once you get a good result.
But be honest: always looking for a new solution to the same problems reduce your effectiveness as a developer , because you are wasting a lot of time in the process. It should not be forgotten that software development is also an engineering, and that therefore in many cases there will be common rules to solve common problems.
Always look for a new solution to the same problems reduces your effectiveness as a developer. Design patterns cut that point. Once you know them, you will have a set of “tricks”, rules, and proven tools that will allow you to deal with most of your problems directly , without having to think about how valid they are, or if you can Have a better alternative.
2. They help you to be sure of the validity of your code
A little related to the above, whenever we create something new, we are in doubt whether we are really giving the correct solution, or if there is a better answer. And the issue is that it is a very reasonable question and that in many cases the answer is the one you do not want: yes there is a more valid solution, and you have wasted your valuable time in implementing something that, although it works, could have been better modeled.
Design patterns are structures tested by millions of developers over many years , so if you choose the right pattern to model the right problem, you can be sure that it will be one of the most valid solutions (if not the best) that you can find.
3. Establish a common language
All other reasons pale before this one. Modeling your code using patterns will help you explain to other people, know your code or not, understand how you have tackled a problem . They also help other developers understand what you’ve implemented, how and why, and also quickly find out if that was the best solution or not.
Design patterns provide a common language among all team members. But it will also help you to sit down with your colleagues to think about how to solve something, and agree much faster, explain more easily what your ideas are and the rest understand it without any problem. The design patterns will help you and your team, in short, to move much faster, with a code easier to understand for everyone and much more robust.
How to identify which pattern fits your problem?
Unfortunately, I have bad news here… This is the most complicated part, and the most obvious answer, which is also the least we like, is that you learn by practicing . Experience is the only valid way to be more skilful by finding out which design patterns can help you.
Of course, there are known situations in which a pattern or another can help us, and I will comment on them throughout the articles. Also I recommend you read the book of Head First Design Patterns, in which in addition to explaining the patterns in a very enjoyable way, explain very well how to use them in real life.
But beyond that point you are all alone. You will need to know what kind of problems each one solves and how to apply them to specific cases . In this case the best thing that can happen to you is that you find a companion that dominates these problems and make them your mentor. Stick to it and express it until you have all your knowledge. Otherwise, practice, practice and practice.
List of design patterns
This is the list of the best known design patterns. Little by little I will try to write articles about each one of them and I will link them here. It is a long process because there are many and I want to find the best way to explain them, but the day will come when we have here a complete list that serves as reference.
The patterns are divided into different groups according to the type of problem they solve , namely:
They are the ones that facilitate the task of creating new objects , so that the creation process can be decoupled from the implementation of the rest of the system.
The creative patterns are based on two concepts:
- Encapsulate knowledge about the specific types our system uses. These patterns will normally work with interfaces, so the specific implementation we use is isolated.
- Hide how these concrete implementations need to be created and how they are combined.
Creational patterns facilitate the task of creating new objects encapsulating the process. The most famous creational patterns are:
- Abstract Factory : Provides an interface that delegates the creation of a set of related objects without having to specify at any time what the specific implementations are.
- Factory Method: Exposes a creation method, delegating to the subclasses the implementation of this method.
- Builder : Separates the creation of a complex object from its structure, so that the same construction process can be used to create different representations.
- Singleton: limits to one the number of possible instances of a class in our program, and provides a global access to it.
- Prototype: Allows creation of objects based on “templates”. A new object is created from the cloning of another object.
They are patterns that facilitate the modeling of our software specifying how some classes relate to others .
Structural patterns that specify how classes relate to each other. These are the structural patterns that defined by the Gang of Four:
- Adapter : Allows two classes with different interfaces to work between them, through an intermediate object with which they communicate and interact.
- Bridge : Decouples an abstraction of its implementation, so that the two can evolve independently.
- Composite : Facilitates the creation of structures of objects in tree, where all the elements use the same interface. Each of them can in turn contain a list of those objects, or be the last of that branch.
- Decorator : Allows to add extra functionality to an object (dynamically or static) without modifying the behavior of other objects of the same type.
- Facade : A facade is an object that creates a simplified interface to deal with another part of the more complex code, in a way that simplifies and isolates its use. An example might be to create a facade to deal with a class from an external library.
- Flyweight : A large number of objects share the same object with common properties in order to save memory.
- Proxy : A class that functions as an interface to anything else: an Internet connection, a disk file or any other resource that is expensive or impossible to duplicate.
In the latter group are found most of the patterns, and are used to manage algorithms, relationships and responsibilities between objects .
Manage behaviour patterns algorithms, relationships and responsibilities between objects. Behavioural patterns are:
- Command : These are objects that encapsulate an action and the parameters that need to be executed.
- Chain of responsibility : it is avoided to couple the sender and receiver of a request giving the possibility to several receivers to consume it. Each receiver has the option to consume that request or pass it on to the next one within the chain.
- Interpreter : Defines a representation for a grammar as well as the mechanism for evaluating it. The language syntax tree is usually modeled using the Composite pattern.
- Iterator : Used to be able to move through the elements of a set sequentially without having to expose its specific implementation.
- Mediator : Object that encapsulates how another set of objects interact and communicate with each other.
- Memento : This pattern gives the ability to restore an object to an earlier state
- Observer : Objects are able to subscribe to a series of events that another target will emit, and will be warned when this happens.
- State : Allows you to modify the way an object behaves at runtime, based on its internal state.
- Strategy : Allows the selection of the algorithm that executes a certain action at runtime.
- Template Method : Specifies the skeleton of an algorithm, allowing subclasses to define how they implement the actual behavior.
- Visitor : It allows to separate the algorithm of the data structure that will be used to execute it. In this way new operations can be added to these structures without the need to modify them.
As you can see, we have a very varied list of patterns that give us the opportunity to create our code much more easily with tried and tested structures that work . The greatest complexity lies in knowing when to use them, something that will come only with the practice.
It is logical that only with the small definition that I have given you do not finish to understand for what they serve some, for that reason I will be creating articles for each one where to speak of them in depth.
There are many other design patterns in addition to those defined in the Design Patterns book of the Gang of Four, which I will add to this list if you find them useful.
And you, what do you think are the most useful design patterns? Did you already know them all? Tell me in the comments.