Call me a perfectionist, but I often have issues when trying to come up with a good design. Every design I come up with, I find a couple of things I don’t like and that I would like to see improved. As a result I spend a lot of time on trying better designs, even if the impact of it isn’t that big. It can take up so much time of me going back and forth on a design that I just have to tell myself to settle for my current best design. In this blog post I will go deeper about my thinking and feelings when faced with this issue.
One of the biggest missing features of the current Object Saving Framework is that there is no native support for lists. There is a way to bypass the issue, but it’s a nasty one. In this blog post I first go into depth about how to bypass the issue, this will make it clear that native support is essential, and finally I will discuss some issues with supporting it.
Recently I have been reworking some code to instead of accessing the database directly, to use an API through a ‘server’ application instead. The main idea behind this was to have a single source of truth. Getting rid of any syncing problems in case the database would change as well as preventing duplicated code.
However, the amount of data you want to transfer from server to client is a lot less compared to having an application that can access the database directly. Instead you want to have a pagination concept where you request a certain amount of rows and request subsequent results if there are. As soon as you think about something like that the Cursor concept comes to mind. Needless to say, with the power of hindsight, using that was not a good idea.
Many applications allow for some level of configurations, ranging from the location where the log files should be written to the connection settings of a database to application specific parameters. But with configuration comes an extra level of potential error. What if the configuration (probably file) is not specified, what if there is an error in the configuration, and should you force the user to set all of these configuration values?
All of these are important decisions that need to be made and they can not be neglected. I will discuss a couple of different views and options you have and what are their benefits and drawbacks.
One of my biggest remarks when working with Java the past few years was the lack of a strict immutability concept. The most you can do is declare your object to be final, which only prevents changing the object being pointed to and not any changes made to the object itself. I remembered that C++ offered a lot more opportunities for this and you could go crazy with the ‘const’ keyword.
However, during some quick investigation regarding this constant behaviour for the GroceriesInsight project, I discovered that I was a bit off with how C++ handles the constant behaviour of arguments passed to a function.
As it goes with all software, initially you think you have it all figured out and it’s all clear, but as soon as you start writing it you realise there are a couple of things not as straight-forward as you would have liked. The implementation of the ObjectSavingFramework is no exception to this, even though it was designed to be a very simple application.
The first version only had to have 3 different concepts:
- Objects: which contains other elements (potentially other objects).
- Values: which just indicate a certain value.
- References: pointers to objects.
The references are an important aspect to avoid infinite nesting, or object duplication. An object that contains another object will have to decide whether this object is private to him, or if it is shared. If it is a private object, the whole object needs to be written as a child element, if it is shared then the reference is required. It is however this reference concept that caused most of the problems.
A common part of any application is to save data, altough there can be a big difference in the reason why you are saving data. Maybe it is just the output of the application which takes a certain input, processes it and writes some output again. But a lot of applications save data to have some kind of memory in case it is shut down, or in case of a failure. A lot of applications wouldn’t be thinkable without any way of storing data for later usage, even simple ones. I recently encountered this with the GroceriesInsight application, which currently doesn’t do much, but even then I already felt the pain of not being able to save the data.
Because of this saving data is a well known process that holds little secret. The first thing you would decide would be in what format you want to save your things, this can vary from a text format such as XML, JSON to a database. Once decided you will search for a library that makes it easy for you to write the data in a correct format. But then you are faced with how to get your data from the object to the library to save it, this problem will the be topic for this blog post.