FAQ about patterns

Today I want to write about some questions people are asking me about the patterns' subject.

You could read this post in Spanish here.

What are they?

Patterns are verified solutions to recurring problems in design and software development. For a solution to be considered a pattern, it must have some characteristics, such as to demonstrate that it can be applied in different technologies, meaning that it is an agnostic and reusable knowledge that can be broken down into well-defined roles or responsibilities, and has demonstrated its effectiveness under certain circumstances. These circumstances have been given the name of forces and are the reasons to use the pattern and to identify it from a different one.

Why I have to know them?

Luckily, there is not a single reason! But there are several reasons for you to know them.

Because you do not need to re-invent the wheel. Patterns try to avoid the repetition to search for solutions from problems already known, so you do not re-invent the wheel.

Because you will go on the shoulders of giants. Yes, yes ... You will be applying solutions that hundreds of architects with a lot of experience have used and refined over the years.

Because they will help you to structure your code. Patterns have well-defined roles or participants. For example, in an Observer pattern, there is the observer and the observed subject. This way you will avoid programming everything together in a single class.

Because they will be part of your developer jargon. This is like police saying "it's a 3218" and understand it they alone. With patterns, you will say "You have to do an Abstract Factory" and all the developers should know what you are talking about. Moreover, they should think about the different roles of the pattern.

Because you will formalize the design. Neither reaching to the extreme case of "To a hammer, all problems look like nails", nor pretending to eradicate creativity, what patterns search for is if your solution has encountered a problem that has an already tested solution. If you have a tree structure in your solution you should encounter yourself with a Composite pattern.

Because they are becoming more known. In recent years, I have seen how different languages and frameworks were adding patterns. Some of them are:

1. Iterators (foreach) in OO languages.
2. Abstract Factory in ADO.NET to create connections and commands.
3. WPF and command to execute UI actions.
4. Aspnet and the radical change in the use of MVC to handle HTTP requests.
5. Js Frameworks which have observables or are MV* (Knockout, Angular, Aurelia, Vue, to name a few) to keep the HTML updated.
6. Rx.Net and the use of *observables.
7. NodeJs and its event loop. If you want to know why Node is so fast you should know this pattern.
8. Redux and its immutable state.

If someone approaches you and tells you that patterns are a waste of time and are used by only 4 geeks, you already have arguments to say that it is not the case.

Because they will be the best professional investment you can make. This is not a Javascript framework that appears today and in 6 months appears another one, and you have to be jumping from a "Getting Started" to another. This is a basic knowledge that you then apply in different programming languages. If you still have doubts I'm going to tell you my experience. I learned about patterns before the year 2000. At that time I was programming Visual Basic 6, that was not 100% object oriented because it had interfaces, and it hadn't inheritance. I started to develop patterns that were based on interfaces like the adapter or strategy pattern with VB, and for those languages which used inheritance, I started to write them in Java until on 2001 I could start doing on C #. About 2 years ago, I had to work on a project where I applied user interface patterns with typescript. How much technological knowledge can you use after 15 years?

But I am already doing this !!

It's possible that if you structure your code well you are already using some pattern without knowing it. If you are in that group, you are a machine! Now learn the pattern's name and you will be able to communicate better with other programmers.

Do I need to know them all?

No, it's not necessary. My advice is to first try to link the problem - or as I said at the beginning, the forces - and the name of the pattern that solves it. When you have the problem, remembering the name you can search the internet to see some implementation in a blog or in GitHub. Then start to learn well the ones you see more often.

What you must know is that there are different patterns for different paradigms or scopes. To name a few you have patterns for object-oriented programming, functional programming, cloud, concurrency, domain driven design, etc.

What's the difference between development principles?

I'll explain it with an example. If you want to design a car that has adhesion, you have to do it with front-wheel drive. This is an example of a recurring problem and linked solution, namely a pattern. Following the example, the principles would be the basic rules for an engine to work.

Development principles are a guide that helps you have an easy-to-maintain and an easy-to-change code, and not being fragile in the face of change - something you touch on one side and stops working on the other side. To me, development principles are before patterns, and patterns often apply these principles.

Do they always have to be used?

No, forcing the use of a pattern is often a mistake. Let's go back to the previous question for a minute. There is a principle called YAGNI, which comes to say to not do something you do not need. And believe me, there are two things you will never need, a poorly built architecture and an over-architecture, which in the end is nothing more than a poorly built architecture.

Conclusion

I have used patterns for over 15 years and I will continue to use them for the advantages they offer. I urge you to learn about them and also use them. The benefit cost is amazing.