Using A Configuration Class (For All Constants/Magic's)

Question

I come from a background where using a configuration file for every, if not every, constant is the best solution for maintainability and flexibility of the program. By this I mean, every hard coded string, integer, table/array, boolean, color, formatting expression, etc. are all put in one file or class (often called the "Configuration" class).

A big benefit to this solution is that is future proofs "accidental" code changes that can introduce new "features" when a main class or code block is modified. I find that it gets developers out of code areas that should not be touched without really thinking about it. It also makes a code in a main class or section much more readable and coherent (see below):

if (x == 5)
{
    // Logic here
}

Versus

if (x == Config.MaxNumberOfResults)
{
    // Logic here
}

the later being MUCH more readable and coherent (especially in the future) and requires little to no comments to maintain as well as no logic needs rewriting if we decide we want a higher max of results.

The issue with the former code is that some other developer would eventually figure out that 5 is the max result limit and then think I want something different than that so (a few attempts later) they include that number (because god-forbid changing the number) thus putting >= now so the entire code block changes...which may introduce a "feature" somewhere else later on down the line. Using the configuration method would result in most developers never even touching the main logic (usually).

The problem is that my boss likes the idea, but wants to leave some constants in main code files even if they are only used once (i.e. that 5 or max result is only used once (right there), so does it really make sense to put a reference to it from another class/file?) I, of course, think so because of the aforementioned reasons as well as it is just cleaner and more coherent code.

Is my thinking more inline with correct coding conventions/methodologies or is my boss'?

I am fine with doing it his way, but it just feels like it will come back to haunt me later on down the road.

Answer 1

One thing to consider is that by introducing a Config class you introduce additional dependencies into your code. Many, if not all of your classes will depend on this Config class. (Such a class is sometimes called a dependency magnet.) Even a class that uses only a single constant from the Config class basically has access to all of them. This is the opposite of encapsulation. Depending on your IDE it will also be hard to find out which constant is used by which classes.

To reduce dependencies and to improve encapsulation, I suggest the following:

1. If the specific constant value if essential for the algorithm and it makes no sense to modify it, just use the value wherever needed and don't define anything. Example: Calculating a cross product only works in 3 dimensions. So just write "3" wherever needed. Don't declare NumberOfDimensions=3 because this would give the impression that this value can be modified.

2. If a constant is only used in one function or class and it is unlikely that it will ever be used somewhere else, declare it locally or as a class attribute. This also works for class hierarchies if you put the constants into the base class.

3. If it is used by multiple related classes (a module) that do not have a common base class, declare a module specific Config class.

4. If the constant is really needed by almost all of your classes, then put it into your global Config class. I believe that this is relatively rare case. An example would be a log file name and log level.

Answer 2

You're asking us to choose between two unnecessary evils.

Give numbers meaningful names. A configuration file can do this but is not required. Local constants, injectable or not, can give them names as well. There is no good excuse to let magic numbers run around naked. Context can make the meaning seem obvious but context can change. Favor readability.

One configuration file to rule them all is a doomed plan on anything but the most trivial projects. Give each configuration file a good name that makes clear what does and does not belong in it.

There is no substitute for taking the time to give things good names.