Should my program's "services" be responsible to get their own configuration?

Question

My program consists from several "services" (I'm not talking about SOA, so don't get confused), and each of these "services" is using some configuration (for example, a directory path). This configuration should be read from a configuration file, as they tend to change (without changing the program's logic, that is).

So my question is this - Should each "service" receive its configuration when invoked, or should it be responsible for getting its own configuration?

This question is actually very similar to this question, only mine is more specific about these:

• My program's "services" aren't generic, and aren't supposed to be re-used by another. They already use generic tools, and their functionality is to simply connect between those tools. This means that it is not immediately obvious for them to receive their configuration, as their target is very clear and direct.
• The target of these "services", being clear and direct, sometimes requires more than one action. This means that my "services" aren't necessary responsible for only one action (although you might separate between logic and preparations such as configuration).

Thanks.

Answer 1

I would advocate a combination of these approaches, as long as you manage to implement it in an elegant way (I have seen this done in both elegant and horrendous implementations):

• Have a data structure for configuration that can implement settings sub-sets (in Perl it is extremely simple with super-imposed hashes, in other languages it's a bit more wordy but overlaying maps on top of each other works as well). To try to be more precise, your data structures will be

  • A global Singleton Configuraton map

  • A "passed as parameter" local configuration map

• Have a Configuration loader class, which can:

  • Take "passed as parameter" local configuration map

  • Take a set of keys needed by the component

  • Superimpose the local map onto global configuration map

  • Allow the components to query out the values from combined map.

• This way, each caller of the services has a complete freedom to either live in a worry-free word and let each service take care of its own configuration needs, or for a more controllable behavior, has an option of passing specific configuration settings it wants to control to the service (either creating the settings values by hand, or cloning data subset from global configuration and adjusting it).

This has major testing benefit, since the test framework can pass specific configuration local overrides needed for each test.