Too many flags when initializing an application?

Question

Building projects

There is a web application that collects itself piece by piece and depending on the config passed at the start. In this case, anything can happen, therefore, in order to ensure stability, pieces with code like if (configLoadedFlag == true && frameworkLoadedFlag == true) {} else {} are scattered throughout the code and, naturally, a crash with logging in critical cases. I would like to reduce the number of branches / streamline the flags. I remember something from the patterns was about this.

Answer 1

Hide all the flags that are “smeared” over the code inside a separate class, which, depending on their state, generates (Factory and Strategy templates) objects that perform the desired functions. This will reduce the number of branches and reduce the coherence of the code.

Answer 2

As far as I know, there is a strategy pattern for avoiding a bunch of ifs. But I'm not sure if it will suit you, because. on idea with it it is necessary to work with a configuration (set of flags in this case). And the fact that you have ifs scattered throughout the code increases its coherence. Since you say that you have a lot of "pieces" that depend on each other, maybe you should use Dependency Injection ?

Answer 3

And checks of these flags are somehow connected?
For example, can configLoadedFlag && frameworkLoadedFlag mean something coherent? In this case, it would be good to encapsulate just the validation logic in one class, perhaps checking the value of the Flagged enum. If there is approximately a combinatorial number of different combinations (and they are not related in the described way), this will not work.

Answer 4

If each set flag performs its own more or less independent set of operations - indeed, as described above - it is better to isolate the interface for working with this “configuration”, and implement the necessary logic by registering action-flag mappings.
Here and IoC just can be used.

Answer 5

A set of commands has already been implemented inside. They are all executed sequentially if everything goes well, however we are not in a perfect world and something is constantly falling down. Perhaps the server did not return the config, perhaps the config turned out to be invalid, perhaps the server with the code of external libraries fell off. As a result, we re-request the config 3 times or, depending on the error, we try to ask for libraries from another place, etc., etc. If we consider configLoadedFlag && frameworkLoadedFlag then yes it is holistic. This means that we have downloaded everything necessary and can start the application itself. If any of the 2 is still in progress, then you need to wait. Accordingly, another flag of the socketConnectionReadyFlag type can be added here.