Use special FsfwFactoryObject instead of functions #451
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
This is something for a future release..
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?