When we start to study Design Patterns it is very common to feel an uncontrollable impulse to apply everything we have just learned in a real world project, sometimes even as a way to validate our knowledge, however such excitement can lead to several side effects, be they in the way of thinking our solution or even in the path that the project we are developing can take, depending on what is implemented.

In this article I will discuss Design Patterns Obsession and explain why you should avoid it.

What are and what are not Design Patterns?

A Software Design Pattern is a general, reusable solution to a common problem that comes up time and again in real-world application development. The pattern generally shows relationships and interactions between classes or objects. Design Patterns are agnostic to the programming language and they represent ideas, not specific implementations.
By using Design Patterns, you can make your code more flexible, reusable, and maintainable.

Reread the given definition again and pay attention to these two key points:

1. “solution to a common problem that comes up time and again”
2. “they represent ideas, not specific implementations.”.

As much as Design Patterns are about solving "Common Problems" through ideas and not specific implementation, it takes some experience to identify them, but one of the common mistakes that developers make is trying to come up with a ready-made (generic) solution to specific problems, before even analyzing the problem and understand in depth what the Pattern intends to solve, especially when they have just learned Design Patterns and this ends up becoming a False Shortcut.
Design Patterns are Not Recipes! and it is necessary to make a clear distinction between them and ready-made solutions.
There is an obvious variation between projects and as much as there are similarities in the application of patterns, in most cases the problems will be at least a little different, meaning we must understand the context behind each project and the problem that we are trying to solve.

Focus on solving the problem First

Note that the "ready-made mindset" reverses the focus and the main point of your thinking becomes the Pattern rather than the Problem (Solution).

The best you can do is focus on the raw solution first, solve the problem as simply as possible and then reflect on the scenarios and analyze the code so that you can get a better view of Problem x Solution, consequently it will become easier to recognize the use case of some patterns, especially when the first implementation becomes verbose and difficult to understand (I'm basically talking about refactoring), but of course, depending on your experience level you will be able to identify design patterns more easily.

OOP and Design Principles before Design Patterns

Knowing Object-Oriented Design Principles and applying Software Engineering Principles to your code like SOLID, DRY, KISS and YAGNI is much more important than knowing all the Design Patterns.

As mentioned before, if you stay focused on the problem and use the mentioned principles above correctly the Design Patterns will come out naturally and sometimes you will likely implement them without even realizing it.

Over-Engineering

Don't try to tweak a system around a Design Pattern, and more importantly, don't force the use of patterns, just try to think of them as a set of solutions to reduce the amount of design work you have to do, but remember, always be careful about over-engineering your solutions as this can lead to unnecessary complexity which in the future could lead to serious side effects such as difficulty maintaining and understanding the code.

After all, when to use design patterns?

Patterns are recognized from several occurrences of a similar situation and you will be more able to identify these patterns as you gain experience, however common sense can be a great ally in the decision of whether or not to use a certain pattern in a solution. First, once you have an initial solution working ask yourself:

Is my code...

• Readable?
• Following the best Clean Code practices?
• Redundant?
• Performing well?
• Using OOP properly?
• Following SOLID principles?
• Testable?
• Expressive?
• Maintainable?

And after refactoring whether or not you apply a certain pattern, ask yourself the same questions again.

Final Thoughts

A Design Pattern is just a tool, and like any other tool if you use it incorrectly it may not achieve your goal, or it could cost you much more than usual to achieve it.

Design patterns perform much better if used in the context of refactoring, when added (or forced) to the initial design, we are at great risk of having an inappropriate solution in the future, especially when you have no experience with similar scenarios.

Don't let Design Patterns affect your critical thinking and mental clarity when solving a problem. 

Keep your focus on solving the problem!