As a little kid, my parents would always force me to wear a life vest when we went to the beach or to water park. I wanted to be the cool kid that just jumps into the water and swims like a mermaid, but what I did instead was to float like a buoy and look extra fat. I absolutely hated wearing that dumb and fat neon-orange vest. So one day, being the reckless kid I was, I started walking away from my parents who were putting on sunscreen, pretending as if I was going to play with the sand. When I was far enough to be completely blend in with the rest of the crowd so my parents couldn’t spot me, I ran straight into the water. Finally! The time has come for me! I will swim like a mermaid!
Well, in case you couldn’t figure it out, I almost drowned.
I was about 5 years old at the time. I didn’t know how to swim. When I realized it was too late, it was really too late. If people around me didn’t have the heart to drag me out of the water, I wouldn’t be writing this at this moment. I at least learned my lesson and started wearing the life vest religiously, thanking whoever that thought of making such things to prevent people from dying.
It could be interpreted as an extreme analogy to use, but design pattern serves like a life vest, providing some kind of aid to the programmers who are about to jump into the vast sea of information and problems, so they don’t get sunken into the ocean by a problem that already has a solution proven by various programmers. The parents who force the little kids to wear life vests are the experienced geniuses, such as The Gang of Four and many other famous computer scientists. Of course, we can always dive into the ocean without life vests, but wearing a life vest, especially when the ocean is deep and unexplored, can guarantee safety and shorten the time spent in the sea.
Over the past couple years, my experiences with computer science were solely focused on coding and completing assignments on time. Until a few days ago, I didn’t know what design patterns even meant; in all honesty, I thought it was referring to the UI of websites. Hence, learning about design patterns was quite a journey. I caught myself wondering why we even had to learn about them… until I realized that my life as a beginning programmer has been so much easier because of them. Design patterns, essentially, are the optimized and reusable solutions categorized by different types, and created by the skilled intellectuals who saw the recurring issues and wanted to increase the recyclability and efficiency of programming. It’s not specific to any language or situations and cannot be treated like algorithms, as they are not modified and used directly in programs. However, they behave as solution templates that can guide the programmer through the issues, and can be modified to create new design patterns.
Although I was never aware of the presence of design patterns, they have been around me and demonstrated in many coding assignments I have done over the years. The most prominent one is the factory method pattern, which allows defining an interface for creating an object, but differs instantiation to subclasses. I’ve had cases where given a class, I had to create different subclasses of the class. Using the factory method pattern, I have been able to create instances of the subclasses depending on the condition and situation, without being limited to producing only a certain amount.
Another design pattern I have used is the decorator pattern. Decorator pattern allows the addition of new or improved behavior of an object, depending on the situation. A way to look at this decorator pattern is using a cake decoration as an analogy; we have a round cake sheet, which is the decorator class. Any other options that we add onto the sheet depending on what we want, such as chocolate, fruits, whipped cream, cheese, etc., belong in the concreteDecorator class. This pattern is used widely as there are different layouts or styles that we prefer in specific settings (e.g. websites and different pages that they have).
A design pattern that I have encountered recently is the observer pattern. It is defined as notifying a change to a number of classes and the classes notified behaving differently depending on the condition or situation. This pattern is represented well in Meteor, because it is essential to the flow of the data built within Meteor. It works by having a publisher, who sends the messages, and a subscriber, who receives the messages. The publication method in Meteor publishes a set of data, and the subscription method subscribes to a set of data to behave (e.g. display certain components or perform some kind of action). Together, the subscriber modifies its behaviors depending on the condition or results obtained from the publisher. The observer pattern that occurs in this case is like the middleman, that makes sure that the subclasses are notified of the conditions of the class and adjust their behavior accordingly.
Learning about different design patterns and understandig how they are implemented into the things that we do as programmers can be tough obstacles to overcome. Some might believe that it is unnecessary to have design patterns and is even trivial in programming. Well, while the belief can’t be declared entirely false (because we all feel and think differently), it is not quite true either. No matter how experienced one thinks he/she is in programming and coding, unforeseen events do happen, and we want to minimize those events as much as possible, quite like how wearing life vests seems dumb until you see your life flash before your own eyes.
I leave the question up to you; at the end of the day, no one–not even your parents– can force you to wear the vest if you absolutely don’t want to. However, speaking from my own experience, I’d make sure to wear the life vest around the ocean no matter how shallow the water is; one can never be too safe and wise about dealing with issues in both life and programming.