Once you have started your carreer as a software engineering it is almost imposible not to hear about design patterns, and the more that you go further your career the more important this topic becomes.
In order to understan what a design pattern is, we must see the definition of pattern, a pattern can be describes as a repeated or singular way in which particular things are done, what this definitions ways is that a pattern is like a serie of steps that ,must follow an order.
We are going to make a bowl of cereal
- First put the bowl
- Then put the cereal
- Then pour the milk in the bowl
- Finally enjoy
This is the most common way to make a bowl of cereal, because in this way all the cereal gets milked, even though there are other ways to make a bowl of cereal, like pouring the milk before, the result may not be the same, or at least a little bit different than normal.
Thats basically how a pattern works, and it is no different when we talk about design patterns in computer science, as we previously saw, design patterns are must not define the final product, but a serie of instructions that may lead you to the final product, defined as repetable solutions that allows users to solve common problems.
One of the best things about design patterns is that because they are meant to solve common problems, and common problems occur quite often, these patterns are always improving, which helps to make them more usefull.
There are two types of design patterns: structural or behavioral
Behavioral
This kind of patters focus in the object comunication patterns, which focuses on functions instead of rules, most commonly followed by:
- Chain
- Iterator
- Mediator
- Observe
- State
- Visitor
Structural
On the other hand, structural focuses on object and class compositions, in which it is defined the ways to compose new objects in order to obtain new functionalities
Some of the different methods in structural design are:
- Separating object’s interface from it’s imlementation
- Compose objects intro tree structures to easy manage
- Add responsabilities to objects
- Creating classes that represents a subsystem
My personal opinion
This is something that I definetely have struggled with, because when you are working in a colaborative project the way that your mind works is not the same as your partner, which means that most likely the way that you will work with the code is not going to be the same, this because you follow diferent design patterns, so it can turn out into an spaguetti code, in those cases I think that is really smart to have these kind of programmin strategies because with these design patterns you can divide the main functionality of the software into pieces that can be treated as individuals and finally merge them to obtain a full-well organized software, this is definetely a proccedure that I would consider using next time I’d have a software project.
If you want to know a little more about design patterns check out this video
REFERENCES
Object Oriented Design. (n.d). Design Patterns. Retrieved from: https://www.oodesign.com/
Source Making. (n.d). Design Patterns. Retrieved from: Souhttps://sourcemaking.com/design_patterns


