Best way to provide configuration parameters for objects far away from the starting point

Question

We are developing complex application on the top of the ROS framework in C++ and recently ran into discussion how to provide parameters to the parts of code far away from the starting main().

The application is a kind of a server. It has a listener for incoming requests that then finds a suitable factor for the worker capable of handling the request. The factory then creates the worker (not always the same class) and at this point the worker internals (various methods inside) need parameters that may differ for each worker. The parameters are initially within the configuration file on the file system (same for all objects, with different sections), but they are automatically loaded and parsed as the main node starts.

The parameters are easily accessible in the main() via "node handle" that allows to access them by name, not unlike the system properties are usually accessed. The parameter has one of the few supported primitive types. The type that is differentiated by the name of the method used to access it. Here is the tutorial explaining how the parameters are accessed.

Different developers so far had four approaches:

1. Pass the "parameter handle" as a parameter to about any constructor, making sure each object has access to it. However this limits testability - a "live" handle an complex interface to the whole ROS infrastructure that must be running. Hence any object that relies on it just to be created is not testable with simple Unit tests.
2. Read all required parameters within main() after startup and store either as global variables in class-specific namespace or alternatively as static fields of these classes. This contradicts generic understanding that "global variables are bad". While the variables are not modified after being set on startup, looks like they cannot be declared const at the language level due the need to set them once inside the main.
3. Create the structures containing parameters and pass these around till they reach the constructor where they are used. Different classes need different parameters so we would need to define multiple helper structures, have the code to populate them from node handle and still looks annoying to pass them around.
4. Create the "parameter provider" class that can be either mock (returning the agreed values) or production implementation (wrapping node handle). Most of the developers are used to access node handle directly so this is promising the long way to persuade them to use that mediating wrapper instead.
5. Some proposed, use dependency injection framework. I understand Spring would do for Java but does such a thing exists or is even possible in C++?

Which of these four approaches (or probably some other) would be the most optimal to provide parameters from the node handle far away from where the node handle is easily accessible?

Answer 1

This is somewhat subjective of course, but all of the listed solutions boil down to providing a global access to all parameters to virtually everybody. Effectively making them static/global variables.

There is a 5. solution that is more in line with oo concepts: Refactor/redesign code until all relevant configurable concepts are represented in main().

How is that possible for classes instantiated deep in the application? Redesign, pass a factory to the thing that instantiates it. You can then configure the factory with parameters in the main().

In the dependency-injection domain there is a similar thing called "Propagating dependencies". How to pass stuff directly to the things that need it, without bothering others.

There are several considerations at play:

• Classes should know only the things they directly need. Things they just pass along is cruft and should be removed.
• Classes should not know how config works in the application, nor should they know some config "framework" or classes.
• Configuration values should be normal constructor or method parameters for classes. They should generally not be pulled from some other location.

Summary: You plug your system together in the main() method and it should be configured there also. If that is not possible, redesign until it is.

Answer 2

In a lot of frameworks, configurations are indeed just static (more or less global). Just initialize some sort of a Singleton before everything begins in main(), and then do something like Configurations::GetBool("foo") wherever needed. It should be safe, since this static config object can (and must) be immutable after the initial initialization. Many of the problems with globals and singletons don't apply if you can't set them, and if they are thread safe.

It seems like nowadays, dependency injection is being favored over the static data. Then, you could just create the config provider class that receives a node handle, and inject this config class everywhere you need it.

Answer 3

We decided to include an interface in the style of:

class ISettingsConsumer
{
public: 
    virtual std::vector<SettingIdentifier> requiredSettings() = 0;
    virtual void setSetting(SettingIdentifier setting, std::variant value) = 0;
}

By chaining these consumers we're able to define some setting deep in the application (where it is actually required) without cluttering the classes close to the main(). This baseline can ofc be extended with fancy signaling and registering functionality.

In our case this works flawlessly and cleanly if all classes between the settings object and the consumers implement this interface.