If you are a programmer, you have surely heard of design patterns. It is even possible that you are already using them in your applications.
Design patterns are a very useful tool. Any programmer should know, at least, the most used patterns. And it is that having them in our toolbox can save us a lot of headaches.
Although in this article we are not going to talk about specific patterns, keep in mind that we are referring to patterns applied to object-oriented programming.
What are design patterns?
Design patterns are solutions for typical and recurring problems that we can find when developing an application.
Although our application is unique, it will have common parts with other applications: access to data, creation of objects, operations between systems etc. Instead of reinventing the wheel, we can solve problems using some pattern, since they are solutions tested and documented by many programmers.
Why use design patterns?
As we saw in the design principles article, if we want to develop robust and maintainable applications, we must adhere to certain “rules.” I put it in quotes because although these design rules are recommended (highly recommended), they are not mandatory. We can always decide not to apply them. Although if we do not do it, we must be aware of the reason for not applying them and their consequences.
Design patterns help us meet many of these design principles or rules.. SOLID programming, cohesion control and code coupling or reuse are some of the benefits that we can achieve by using patterns.
How many design patterns are there? Do I have to know them all?
Design patterns there are many. A lot of. And new patterns keep popping up every so often. Application development is an ever-changing discipline. Therefore the problems that developers face also change. So the tools used are also being updated and improved.
It is impossible to know all the design patterns. The most useful thing is to have a pattern catalog that we can consult. When developing an application, we can consult our catalog looking for patterns that help us solve specific design problems.
Some examples of catalogs can be found in OODesign, in Wikipedia, or the now famous book Design Patterns: Elements of Reusable Object-Oriented Software, whose authors are known as The gang of four.
What types of patterns are there?
There are several ways to group design patterns. Perhaps the most widespread is to group them according to their purpose. In this case we would have the following categories:
- Creational patterns: used to instantiate objects, and thus separate the client implementation from that of the objects that are used. With them we try separate creation logic objects and encapsulate it.
- Behavior patterns: are used when defining how classes and objects interact with each other.
- Structural patterns: used to create classes or objects that are included within more complex structures.
Can I develop new patterns?
As I have said before, new patterns or revisions of existing ones appear every so often. It is logical if we take into account that our way of programming is continually evolving. New frameworks, new platforms, new types of data access etc.
Therefore, it is feasible that anyone can “discover” a new pattern. Logically the supposed pattern should be put to the test by the developer community. To do this, you must prove that it is new, that it is correct, and that it is useful for solving common development problems. A pattern will not be such if it only serves to solve a specific problem in our application.
The conclusion is simple, if you don’t use patterns, you should. Patterns help standardize your code, making the design more understandable to other programmers. They are very good tools, and as programmers, we should always use the best tools at our fingertips.
Yes indeed, always with a head and common sense. There is no use applying patterns without good reason.
And you, do you use patterns? Which ones do you use the most?
Image | darkday.