Methods, but for Humans.

05 Dec 2017

We know about methods like the backs of our hands, those useful little blocks of code we write to solve similar, recurring problems more easily and effectively in our programs. But believe it or not, software engineers write methods for themselves too! We call them design patterns, and they’re basically methods that we ourselves follow, in order to solve similar complicated problems while writing software and developing our own programs. Yes, as silly as it sounds, we create methods for ourselves to write programs more easily, which involve writing methods for our programs to solve problems more easily. This loop could go on forever, but it really is fascinating. Just as much as methods make it easier for us to solve problems with our software, design patterns make it easier for us to solve the even bigger problem of how to go about solving the problem. Crazy.

When developing programs, we find patterns all the time in our code, and that’s what makes using methods so useful. We notice similarities between tasks and the code required to execute them, and implement methods which we can then use to solve all tasks following that same structure, with any valid parameters, as opposed to writing the same lines of code time and time again with every occurrence of that task. Fortunately, the same process is effective for determining HOW to solve the problems. As software engineers became increasingly experienced in solving problems, they started to see patterns and correlations between they steps they took to approach and solve different problems, which led them to see similarities between similarly structured problems, and finally, implement problem solving methods using design patterns to tackle any problem following a similar pattern. We learned to do exactly this in our software engineering class through our lesson on Meteor, where we used Javascript classes and objects to represent database collections in MongoDB for developing apps – a great example of the prototype design pattern. At work, I myself am part of an even larger-scale example of the MVC (Model, View, Controller) pattern which models the operations of our whole office, which is structured with three departments specific to the database (model), web designers (view), and developers (controller) working together to develop and maintain the class registration system for the entire University of Hawaii college system.

If you take a moment to think about the way you write your own software, you might realize that you are in fact using various design patterns left and right, without even realizing it! The next time you are faced with that million-dollar question and mother of all problems: “how in the world do I solve this problem”, take advantage of your ability to implement a subroutine for yourself. Analyze the type and structure of your problem. Odds are, the problem you are trying to solve is very similar to the problems that many other software engineers are regularly faced with. With just a little help from the open source community, you’ll soon find a pattern that you can use and implement to solve your problem, both quickly, conveniently, and effectively!