2

My application has a few high level configuration options such as directories which will be used for various things, database connection information and a few other settings which are required for the application to run.

I'm debating with myself whether or not constants are better than variables for this purpose and would like some input.

By having:

 $config = new Config;
 new Whatever($config->foo, $config->bar);

Instead of:

new Whatever(Config::FOO, Config::BAR);

I get the power of polymorphism, I can quickly swap between configuration settings by instantiating $config as a different class with the same class members.

There's obviously a trade-off here. Anything which needs the config options must instantiate a $config object, using memory and creating extra code as well as making it so the config options are no long immutable.

The immutability problem could by solved with a method e.g. $config->get('Foo'); so that is potentially a non-issue, although it does add to verbosity and a method call is more expensive than reading a constant or variable.

1

For configuration options, it is better to use properties (or methods) instead of constants. The reason for this is that configuration options will change when you deploy your application in a different environment.

When using properties/methods, you can opt to read the relevant values from a configuration file at startup, which is not possible if you use constants.

The overhead of creating a Config object can be minimized by having one global object and making that available throughout the application using either Dpendency Injection or the Singleton pattern.
Worrying about the overhead of a function call is most likely premature optimization. It is unlikely to matter and in the rare cases where it does (e.g. in a tight loop), there are other solutions, like reading the configuration value at a non-critical time and caching the value in a property/variable.

  • Depending on the programming language, it's absolutely possible to modify the values of constants. – RibaldEddie Mar 3 '14 at 12:42
  • @RibaldEddie: If the program itself can modify the values of constants, I don't regard those as constants. I will admit that with scripting languages, you can use a source file as configuration file. – Bart van Ingen Schenau Mar 3 '14 at 13:31
1

Constants have a nasty habit of not remaining constant, especially over long periods of time.

If you go down the constants route, then some development tools will extract the "constant" value at compile time and bury that value into whatever code module they're building. Efficient? Yes. But, if you later decide that you have to change that "constant" to some other value, then those "early-bound" application will get broken. Your new code will recognise the new value, but those other components will still be passing the old one.

If you go down the public properties route, then every application will come to your component at run-time to acquire the value and so will always get the right one (unless they've inconveniently written it away into some external data store, of course). Guard against that by not reusing the same underlying values - if you used values 0 .. 3 initially, then don't use any of these values after your refactoring.

Regards, Phill W.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.