Within the next couple of decades, I believe that IT and software development will become an obligatory course for all students in elementary school. You can probably speak to your neighbor, your children and your friends living across the planet about the beauty of programming and discuss the error-prone code you have just written. Templates and design patterns for software development is and will continue to be essential for people to easily cooperate, reuse and maintain code you write. When every human being on the planet will know the basics of software programming, common and widely known design patterns will be the key to avoid an enormous, tangled mess of code bases. It will also help with understanding and learning new languages and their respective frameworks. As an analogy, if you have learned a new language, let us say Norwegian, then you probably have laid the foundation of understanding other Scandinavian and European languages which have similar grammatical rules and vocabulary. The same way goes for design patterns. Once you know the fundamental design patterns needed for writing high-complexity code in one language, you will probably easily adapt to the way another language is implementing these patterns.
An example of a pattern is the observer pattern, where an object, called a subject, maintains a list of dependents, called observers, that notifies the observers whenever a change in a state occurs. This sort of event handling is widely used in many software applications. This spring we implemented an n-elevator-system in Golang. Here we used goroutines and channels as observers to notify all elevators whenever the state of any of the other elevators had changed. The last couple of weeks we have been developing an application to give UH students possibilities to connect with possible career-opportunities through a career-network online using a JavaScript Meteor-framework. Here we have used Meteor’s own Observer-like design pattern publish-describe, where the server publishes collections like profiles, reports and events, and the client subscribes to the collections needed to render the page. The whole notion of reactive data in Meteor is also a version of the Observer design pattern. For instance, when a company is going to add an event to the website, the Events-collection is updated. Code referencing a cursor in that collection will then be re-run such that the new event will be displayed on the events-page.
Another example of a design pattern is the Model-View-Controller pattern, that divides the related program logic into three interconnected elements: model, view and controller. MVC mostly relates to the UI/interaction layer of an application. In our Meteor-application we can divide the system into these elements, with MongoDB as the model, Blaze as the view and Flow Router as the controller. This front-end design pattern can also be seen in more back-end systems, like a helicopter-control system we implemented this spring. In this case, the view of the system is the helicopter’s response and motion to the software. The model is the mathematical model derived and data needed to control the helicopter, while the controller is the PID-regulators and filters needed to control the “view” and motion of helicopter, and to update the optimal parameters of the model.
As I started off with, there is a dramatic increase in the number of people having basic knowledge about software development. As this number continue to increase (along with number of programming languages), the need for having fundamental design patterns will do the same. For the software-world to become successfully globalized, the fundamental differences between programming languages and code segments need to be minimized. Even though it sounds difficult to learn a new language; if the grammar and vocabulary sounds somewhat similar to your own language, you are almost there! Let’s continue to praise the design patterns in order to accomplish our goal: to have 7.9 billion multilingual software-developers ready to hack their way through life.