Move ObjetManager Singleton into ObjectmanagerIF #541

New Issue

mohr · 2022-02-02T18:16:44+01:00

mohr commented

2022-02-02 18:16:44 +01:00

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 ObjectMangerIF.h. ObjectManger is a singleton with a private *ObjectManager instance which is lazy loaded with a new ObjectManager() in ObjectManager::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 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 ObjectMangerIF.

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 ObjectManager as 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 ObjectMangerIF.

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.

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 `ObjectMangerIF.h`. `ObjectManger` is a singleton with a private `*ObjectManager` instance which is lazy loaded with a `new ObjectManager()` in `ObjectManager::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 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 `ObjectMangerIF`. 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: 1. Do a lazy instantiation of an `ObjectManager` as the default implementation. This would stay closest to the idea of a singleton, still allowing to overwrite it. 2. 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 `ObjectMangerIF`. 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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fsfw/fsfw#541