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.
The first thing to add is of course a way to add products and transactions as these form the core of the application. With the initial version I am aiming for a very basic form which just allows storing and retrieving data.
With the initial implementation of the Product and Transaction done, I will briefly explain how everything went, the thought process behind it and what I already know must be added in the future.
In the previous post, I have been examining the C++ build tools that are available. As a good Software Engineer, the next step of course is to choose a testing framework. From my experience with Java, I have a couple of requirements on what the testing framework should allow. Most of these requirements come from using jUnit and Mockito, which I think are both outstanding frameworks that allow you to easily test your code.
For my tests I examine the following libraries: gTest, CppUTest, Boost, CxxTest and FakeIt. Some important features I am looking for is easy testing/mocking, readable tests, and the limitations of the framework.
I remember my time at the university, when working on C++ code, all of the command line commands I executed to get the my to compile and link. For the small projects I did back then, that was more than enough. We did get some small introduction into make, but we didn’t go into detail about how it all worked. When we started to work with Java, we had to use Maven, and again we didn’t get any real introduction. In my short career I have discovered the world of Maven and I am now more aware of how it all works, making me proficient enough to do what I need to manage bigger projects.
My love for C++ however never really faded, and I have been looking into doing some more C++ coding again. To get me started I was investigating build process tools for C++, in my search I found a couple of solutions: CMake, Maven and Gradle. The goal I set out for all of these tools, was to get a simple project and some tests for it to build.