Move ObjetManager Singleton into ObjectmanagerIF #541
I'm thinking about unit tests at the moment and have the problem of replacing the ObjectManager for unit tests.
Since #424 / #426, framework components depend on
ObjectManager.h instead of
ObjectManger is a singleton with a private
*ObjectManager instance which is lazy loaded with a
new ObjectManager() in
If I wanted to install a different ObjectManager, I would need to link in a different implementation. This is quite complex, as I can not reuse the definitions of building the fsfw nominally and need to build a parallel definition for unit tests which need a different ObjectManager which in turn would complicate the cmake stuff signigicantly.
My proposition is to change the singleton instance to
*ObjectManagerIF and move it as a protected static member into
ObjectMangerIF (which breaks a bit of the Interface idea, but as we are not Java, it is legal (we've done such things before)). Alongside, the
instance() would then also move up as a static member into the
This would have two effects:
First, the framework code would be back depending on an Interface, instead of a specific implementation.
Secondly, by inheriting from
ObjectMangerIF, a custom implementation gains access to the otherwise protected singleton pointer and can change it globally (whithout the need for a dirty global variable). I am thinking of a custom class implementing
ObjectMangerIF and setting the singleton instance in its constructor.
For the implementation of
ObjectMangerIF::instance() I can see two approaches:
- Do a lazy instantiation of an
ObjectManageras the default implementation. This would stay closest to the idea of a singleton, still allowing to overwrite it.
- Do not do any instantiation but require the user to supply an implementation by instantiating a suitable one (which would set the singleton instance to itself in its constructor). This has the disadvantage of one more required configuration step by the user and the need to instantiate the ObjectManager before any other
SystemObject. An advantage would be that the user is (painfully?) aware that there might be different implementations for
I think this might also be useful for other singletons (of which I do not have a good overview right now) and open up the possibility of having different implementations available in the fsfw for the user to chose from.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?