Solving the Rubik's Cube of Software Engineering
29 Nov 2018The Best Way to Solve the Rubik’s Cube
Problems tend to get easier over time. Humans are hardwired to notice patterns that aid us in completing things more efficiently. For example, way back when calculus when people were learning calculus and they discovered what derivatives are, they probably noticed after many attempts that there are rules that shorten the calculation significantly. Similarly, when the Rubik’s Cube first came out, no one could Google the answer; there were no robots that solved it using some cleverly design algorithms. Instead, someone fiddled around with it until they solved it. And then they solved it again, and again, and again, until they noticed that they could solve it the same way every single time. Unless a piece was twisted and the Rubik’s Cube was unsolvable, the method that was refined over time was sure to get the job done. The moral of the story is: next time you want to solve a Rubik’s Cube, don’t reinvent the wheel, just look up others did it.
How does this relate?
Like any other problem, Software Engineering followed this same pattern. Some very smart people tried and tried again. Each time evolving there past method of design until we have come to the many modern day design patterns. Rubik’s Cube algorithms and software engineering design patterns are not all that different. For example, the method described on the Rubik’s Cube website is a sure thing to solve the problem, but it is not necessarily the most efficient. Likewise, the use of classes and objects can get the job done in object oriented programming, but there could be better ways. For Rubik’s Cube, there are speed solving algorithms. You have to learn a lot more algorithms and be able to recognize when to use each of them, but you will solve it much faster. For software engineering, the use of the Factory Method is comparable to speed solving. It has the advantages of being able to return objects from other classes, returning multiple objects, or even build additional, dependent objects. However, it comes at the cost of being more complicated than using an object oriented class constructor.
My Experience with Design Patterns
I started learning to solve the Rubik’s Cube when my seventh grade math teacher promised the keys to the kingdom (his guide to solving it) to anyone who could solve one side of the cube. The learning curve was there but I managed, and a few short weeks later, I could confidently solve a Rubik’s Cube without the guide. When I started my journey into software engineering, it took me more than a few short weeks of learning before I was ready to even be given instructions on how to use a design pattern. In fact, they are just now being introduced as a topic now that I have been unknowingly using them for weeks. I assume that just like with the Rubik’s Cube, I have earned the keys to the kingdom. It is one thing to be able to do something and it is entirely different when you understand it. I now know how the singleton is useful for creating a global instance of something that there should only be one of. Reactive Data is used in my current project to re-run content related to the data that was changed. I better understand the interactions between React, React Router, and MongoDB in my project’s MVC design pattern in Meteor.