Move ObjetManager Singleton into ObjectmanagerIF #541
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
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 ofObjectMangerIF.h
.ObjectManger
is a singleton with a private*ObjectManager
instance which is lazy loaded with anew ObjectManager()
inObjectManager::instance()
.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 intoObjectMangerIF
(which breaks a bit of the Interface idea, but as we are not Java, it is legal (we've done such things before)). Alongside, theinstance()
would then also move up as a static member into theObjectMangerIF
.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 implementingObjectMangerIF
and setting the singleton instance in its constructor.For the implementation of
ObjectMangerIF::instance()
I can see two approaches:ObjectManager
as the default implementation. This would stay closest to the idea of a singleton, still allowing to overwrite it.SystemObject
. An advantage would be that the user is (painfully?) aware that there might be different implementations forObjectMangerIF
.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.