How to pass command line parameters to various parts of program

Question

Consider a large program with many different parts that have a single command line interface, as is the case with most applications. How best do I handle passing various command line parameters, that may be meant for various parts of the application, to them?

These parts may be hierarchical, for example, main() instantiates A (which instantiates B, C) and D (which spawns E), and each of them has specific requirements for command line parameters. There are various possibilities.

• Make global variables for the parameters, set them and then just read them as required. Possibly in a configuration namespace or class or some sort.
• Make a HashMap, which maps the command line arguments, which constitutes members of an Enum, to their values. These are strings initially of course, but each part of the program reads and interprets the types as requires. This map is passed hierarchically with each instantiation.
• Make classes for AConf, DConf, which are then populated by main and passed to A, and D resp., from which they make BConf, CConf, EConf, and pass those configuration objects to B, C, E resp.

and many more.

In a large application with various parts, how is this handled gracefully?

Note: I'm not asking about argument parsing. I'm asking how to send the values to different objects after they've been parsed.

Answer 1

For this it is OK to have a static class in a shared library that gets the entire command line at startup. Say you name it CommandLine. You can then create methods like

bool HasSwitch(string)

and

string GetNamedArgument(string)

on it. If you need more sophisticated parsing later you can easily add it.

Answer 2

In complex applications, I see command-line parameters as the highest priority source of application configuration, hence I include their handling in the same logic as configuration information.

In my sense, configuration information is retrieved from (highest priority first):

• command-line arguments
• configuration file provided in command-line arguments
• environment variables
• user-defined configuration file (e.g.: ~/.myapprc on Unix)
• global configuration file (e.g.: /etc/myapprc on Unix)
• default configuration defined at compile time

Answer 3

In a large application with various parts, how is this handled gracefully?

Any of your suggested solutions could work, but as the size and scope of the project increases, each method has its downfall. Ultimately I think this is best solved by a configuration singleton, which can support anything from a hashmap to a getConfigA(...) or whatever specific solution you want.

Equivalently a static function or set of static functions can serve the same purpose; if you need something that feels/smells like a global, a singleton is probably a better solution.

Answer 4

The Parameters-Model-View-Controller Paradigm

In the same situation: many use cases, use cases in a navigation menu, parameters to the use-cases (selection of some category, selection of order item, ...).

We had a classical UseCase<Model, View, Controller> class, but now have a

UseCase<P, M, V, C>
UseCase<Parameters, Model, View, Controller>

So we actually split the classical model into:

• M (mutable) data model, and
• P (fixed parametrisation, control variables/constants, header data)

Indeed Parameters has a different life than Model.

This means that every use case XxxUseCase got its own XxxParameters class. One could very well argue for some kind of scripting / declarative approach; as your mention of hash maps. But if there is no need, a reference from one system component to another is best served by a type-safe, specified, parameter class. Especially if the number and variation of parameters grow.

Answer 5

Usually (barring some very specific requirements) none of the suggested three options is good enough, neither is having a static object. All of these have the same problems: objects are required to know about command line arguments and failure to encapsulate knowledge.

The problem starts at this sentence:

main() instantiates A (which instantiates B, C) and D (which spawns E)

This is not exactly how an object-oriented program should work. All of the program is supposed to be plugged together at the very top of the execution hierarchy, i.e. in the main() method. Objects very rarely directly instantiate each other if at all. We use dependency inversion, factories, and other things to make sure we can separate the instantiation and usage of objects.

If you do this, you will actually instantiate things that matter in your main(), which means you can directly configure them with meaningful values (like a timeout period as Duration) instead of just a bag of strings with no meaning at all.