K
kj
I'm sure this is a simple, but recurrent, problem for which I can't
hit on a totally satisfactory solution.
As an example, suppose that I want write a module X that performs
some database access. I expect that 99.999% of the time, during
the foreseeable future, the database connection parameters will
remain unchanged. The only exception that I envision for this
would be during testing or debugging.
Given all this, I am tempted to turn these connection parameters
into hard-coded module attributes that I can always override (i.e.
overwrite) when necessary.
But for as long as I can remember the dogma has been that hard-coded
values are bad, and that one should use other techniques, such as
configuration files, or parameters to a suitable constructor, etc.
This is where I begin to get confused: whose responsibility is it
to know of and read the config file? I can think of two distinct
scenarios: 1) module X is being used by a large, full-fledged
application A that already uses a config file for its own configuration;
2) module X is being used by a simple script that has no need for
a config file. In case 1 I'd be glad to let application A set
module X's connection parameters using values read from its own
(i.e. A's) config file; this minimizes the number of config files
that need to be maintained. In case 2, however, it would be
preferable for module X to read its connection params from its own
(i.e. X's) config file. In this way the script won't have to bother
setting some parameters that are in fact practically constant...
After going round and round on this, my original idea of hard-coding
the values as module attributes begins to look pretty attractive
again.
How would you handle such situations?
Thanks!
kynn
hit on a totally satisfactory solution.
As an example, suppose that I want write a module X that performs
some database access. I expect that 99.999% of the time, during
the foreseeable future, the database connection parameters will
remain unchanged. The only exception that I envision for this
would be during testing or debugging.
Given all this, I am tempted to turn these connection parameters
into hard-coded module attributes that I can always override (i.e.
overwrite) when necessary.
But for as long as I can remember the dogma has been that hard-coded
values are bad, and that one should use other techniques, such as
configuration files, or parameters to a suitable constructor, etc.
This is where I begin to get confused: whose responsibility is it
to know of and read the config file? I can think of two distinct
scenarios: 1) module X is being used by a large, full-fledged
application A that already uses a config file for its own configuration;
2) module X is being used by a simple script that has no need for
a config file. In case 1 I'd be glad to let application A set
module X's connection parameters using values read from its own
(i.e. A's) config file; this minimizes the number of config files
that need to be maintained. In case 2, however, it would be
preferable for module X to read its connection params from its own
(i.e. X's) config file. In this way the script won't have to bother
setting some parameters that are in fact practically constant...
After going round and round on this, my original idea of hard-coding
the values as module attributes begins to look pretty attractive
again.
How would you handle such situations?
Thanks!
kynn