The topic of this weeks blogpost are Design Patterns.
The definition at the beginning of the wikipedia article states following:
In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.
We did research about different design patterns, like the factory and the observer pattern. But we could not really find a point in our source code where we could apply one of these more common design patterns in a meaningful way.
The reason for this is that we are taking big advantage of the functionalities that our frameworks are providing us. In the case of our frontend this would be Flutter and Angular Dart and in the backend things like Socket IO and Sequelize. This has the result that we are only writing little pieces of independent code. It was difficult to find a Design Pattern with which we could improve our code.
The mentioned frameworks are already providing us with different design patterns, which we didn’t have to implement on our own. The first example for this is the observer pattern, which is provided by Socket IO. The observer pattern is pretty simple and basically consists of two different parts, observers and subjects. The observer subscribes to different subjects of which he wants to gets updates, when changes happen. One observer can subscribe to several different subjects and every subject can have many observers. In our case do we only have one subject which is our webservice on the server. Every client who usese our service ans is logged in subscribes to this subject.
In the end we chose to implement the module pattern in our API-code, in a simplified way. We found that we were using the same function call for Sequelize at different points in our code. To increase the maintainability of our code we moved it into a separate function. Because of this we only had to change the call at this one point, when necessary. For now this seems to be only a minor problem because our project is still pretty easy managable at this size. But as our codebase grows, little things like these are getting more important.
In the following you can see the difference that this change caused in our class diagram. The difference is pretty small, because we only did a minor change to the code.
And here you can see the changes we did in our code: