Starting from the fifth grade, I spent an insane amount of time in robotics club after school. One thing I remember my robotics coach telling me was, “Why reinvent the wheel?” In robotics, I spent a lot of time designing robots for competitions. I often found myself as the lead designer for the team. This short quote from my coach changed my way of thinking when it comes to design.
In my early years of robotics, I wanted to come up with the coolest most innovative solution. I wanted the most complex and intricate robot that would leave everyone in awe. On the first try, I wanted to come up with something that has never been done before. But why reinvent the wheel? When I first heard my robotics coach utter those words I thought to myself, “Isn’t that copying? Isn’t copying bad?” My coach never meant for me to build an exact replica of another team’s robot. The point that my coach was trying to make is that people have spent years figuring out what works and what doesn’t; make use of their experience. Look at how teams designed their robots in the past and understand why they made certain design choices. My coach introduced me to the idea of design patterns.
Once I learned this concept, I noticed so many patterns in team’s design choices for their robot. Every year there would be a new game, a new challenge that teams had to design a robot for. While the game was completely different, I noticed that the main components of robots did not change much. I don’t want to get too technical with all the different design choices but here are a few examples. A very popular lift design was the Six Bar Linkage because it provided a lot of height, was lightweight, and was compact. No matter what the game was, many teams used this design because it had the reach, it was easy to run on the motors available, and could easily meet size and weight constraints. As another example, every year there was a new game object to manipulate and every year teams chose between three or so design concepts for their intake: a shovel, rollers, and a claw. While the specific design for each team varied, at their core they were one of the common design concepts. After doing robotics for so many years, I realized that the robots of the top teams tend to repeat the same concepts over and over. The top teams weren’t only the ones with the most experience but also the ones who stuck with design patterns.
Design Patterns do not just apply to building but programming as well. When it comes to programming, there’s no point in trying to find a new way to store data or to create objects when doing object-oriented programming. Programmers of the past have done all the hard work for you and have found various solutions to your various problems. As a programmer, your job is to understand the different design patterns as well as the pros and cons of each concept. From there you can and choose the best approach. Why stress and spend so much time and effort programming something when there’s a library that does exactly what you need?