Are design patterns always the solution?
It is very common to read that design patterns always guarantee us to solve a problem in the best way, so this means that if I apply many design patterns to my program, will it be easy to understand and also will it comply with the principles of Clean Code? The answer to this is not always, We must be cautious when implementing them, since these are a double-edged sword, and instead of improving our software it can make it worse. A very clear example is the following:
Modularity is a design technique on which many design patterns are based, using these patterns can help make the software structure more organize and easy to understand. In my experience I have noticed that modularity is abused many times, there is a lot of trying to separate the code, many classes are created supposedly to better organize the code, but what this is actually causing is to disperse the logic of the application. This causes many problems such as reading the code, it is very tedious to understand a program in which a function uses another function from another class, and this other function uses another function from another class and so on until the end of times.….Even writing this sounds like a tongue twister and understanding such a system takes too long, this way it can slow down software developers a lot, going from one class to another trying to figure out what is really happening, can be very frustrating.
A common problem that I have noticed when using design patterns in an application is the lack of communication. A great advantage of using patterns is that it is much easier for the team to understand the system since you can simply tell your teammates that in order to make this feature you decided to apply a certain pattern, this way It is very easy to understand the purpose of the code, the problem is that many times it is not very explicit that you used a design pattern, and software developers can take hours trying to understand what is happening with this code, then they will realize this very unusual code is a design pattern, and from now on it is very obvious how the code works. For this reason, it is very important to take into account the communication of the patterns in the system, it can take hours trying to understand the code when a simple name in the class can imply the design pattern used.
Another problem that I have seen when implementing the design patterns is that it is not taken into account how complex it is to adapt the pattern to the program, many times it is better to implement your own solution than to try to fit a pattern where it does not fit, I have seen software that uses a complex design pattern to achieve something that could be easily done in 5 lines of code, so why to make our software more complex? We can design good solutions that can be better than a design pattern for our software.
I am not saying design patterns are bad, but you should be careful when trying to adapt one, be aware that you can make your software worst. If you have a solution and you know it’s a good one, you can use it, don’t try to use design patterns in every part of the system just to feel good because you implemented one or to tell you teammates “Hey, use a lot of design patterns in this software project that’s mean that I am a good software developer!”.
