Use special FsfwFactoryObject instead of functions #451

New Issue

muellerr · 2021-08-04T11:33:27+02:00

muellerr commented

2021-08-04 11:33:27 +02:00

The FSFW uses function pointers to assign the object producer function and declares Factory::setStaticFrameworkObjects as friend, which limits the possible functions to declare those objects to that function only. The second point is especially annoying, because I had to use preprocessor defines in fsfw_tests to allow an external project to specify their own object ID setter function. There is a better way to do both of them at once.

This would require creating a FsfwFactoryObject with at least two virtual functions:

virtual void createStaticFrameworkObjects
virtual void produceObjects

Now, a sensible default configuration can be provided in this function, which can also be overriden by the user. The user creates a custom factory object implementing the FsfwFactoryObject and then passes this object to the ObjectManager. The object manager can then use the object instance to initialize the framework.

This approach could theoretically also be used to transfer more FSFW configuration to one hook class. Benefits:

The user can see all adaption points at once, no need for files which need to be copy and pasted from the defaultcfg folder (which also becomes deprecated really quickly). The defaultcfg folder could still contain a default implementation for the new class which simply calls the base class functions to get started.
It is easy to provide simple default implementations in the configuration class

For example, another virtual function

virtual Returnvalue_t clearMissionMessage(CommandMessage* message)

or a default value for the APID, which can be overriden via a setApid function.

This is something for a future release..

The FSFW uses function pointers to assign the object producer function and declares `Factory::setStaticFrameworkObjects` as friend, which limits the possible functions to declare those objects to that function only. The second point is especially annoying, because I had to use preprocessor defines in `fsfw_tests` to allow an external project to specify their own object ID setter function. There is a better way to do both of them at once. This would require creating a `FsfwFactoryObject` with at least two virtual functions: 1. `virtual void createStaticFrameworkObjects` 2. `virtual void produceObjects` Now, a sensible default configuration can be provided in this function, which can also be overriden by the user. The user creates a custom factory object implementing the `FsfwFactoryObject` and then passes this object to the ObjectManager. The object manager can then use the object instance to initialize the framework. This approach could theoretically also be used to transfer more FSFW configuration to one hook class. Benefits: 1. The user can see all adaption points at once, no need for files which need to be copy and pasted from the defaultcfg folder (which also becomes deprecated really quickly). The defaultcfg folder could still contain a default implementation for the new class which simply calls the base class functions to get started. 2. It is easy to provide simple default implementations in the configuration class For example, another virtual function ```cpp virtual Returnvalue_t clearMissionMessage(CommandMessage* message) ``` or a default value for the APID, which can be overriden via a `setApid` function. This is something for a future release..

muellerr referenced this issue

2022-10-17 15:18:08 +02:00

remove ObjectManager production callback #696

Sign in to join this conversation.