Best way to load application settings

Question

A simple way to keep the settings of a Java application is represented by a text file with ".properties" extension containing the identifier of each setting associated with a specific value (this value may be a number, string, date, etc..). C# uses a similar approach, but the text file must be named "App.config". In both cases, in source code you must initialize a specific class for reading settings: this class has a method that returns the value (as string) associated with the specified setting identifier.

// Java example
Properties config = new Properties();
config.load(...);
String valueStr = config.getProperty("listening-port");
// ...

// C# example
NameValueCollection setting = ConfigurationManager.AppSettings;
string valueStr = setting["listening-port"];
// ...

In both cases we should parse strings loaded from the configuration file and assign the ​​converted values to the related typed objects (parsing errors could occur during this phase). After the parsing step, we must check that the setting values ​​belong to a specific domain of validity: for example, the maximum size of a queue should be a positive value, some values ​​may be related (example: min < max), and so on.

Suppose that the application should load the settings as soon as it starts: in other words, the first operation performed by the application is to load the settings. Any invalid values for the settings ​​must be replaced automatically with default values​​: if this happens to a group of related settings, those settings are all set with default values.

The easiest way to perform these operations is to create a method that first parses all the settings, then checks the loaded values ​​and finally sets any default values​​. However maintenance is difficult if you use this approach: as the number of settings increases while developing the application, it becomes increasingly difficult to update the code.

In order to solve this problem, I had thought of using the Template Method pattern, as follows.

public abstract class Setting
{
    protected abstract bool TryParseValues();

    protected abstract bool CheckValues();

    public abstract void SetDefaultValues();

    /// <summary>
    /// Template Method
    /// </summary>
    public bool TrySetValuesOrDefault()
    {
        if (!TryParseValues() || !CheckValues())
        {
            // parsing error or domain error
            SetDefaultValues();
            return false;
        }
        return true;
    }
}

public class RangeSetting : Setting
{
    private string minStr, maxStr;
    private byte min, max;

    public RangeSetting(string minStr, maxStr)
    {
        this.minStr = minStr;
        this.maxStr = maxStr;
    }

    protected override bool TryParseValues()
    {
        return (byte.TryParse(minStr, out min)
            && byte.TryParse(maxStr, out max));
    }

    protected override bool CheckValues()
    {
        return (0 < min && min < max);
    }

    public override void SetDefaultValues()
    {
        min = 5;
        max = 10;
    }
}

The problem is that in this way we need to create a new class for each setting, even for a single value. Are there other solutions to this kind of problem?

In summary:

1. Easy maintenance: for example, the addition of one or more parameters.
2. Extensibility: a first version of the application could read a single configuration file, but later versions may give the possibility of a multi-user setup (admin sets up a basic configuration, users can set only certain settings, etc..).
3. Object oriented design.

Answer 1

Essentially the external configuration file is encoded as a YAML document. This is then parsed during application start up and mapped to a configuration object.

The final result is robust and above all simple to manage.

Answer 2

Let's consider this from two points of view: the API to get the configuration values, and the storage format. They are often related, but it's helpful to consider them separately.

Configuration API

The Template Method pattern is very general, but I question whether you really need that generality. You'd need a class for each type of config value. Do you really have that many types? I'd guess that you could get by with just a handful: strings, ints, floats, booleans, and enums. Given these, you could have a Config class that has a handful of methods on it:

int getInt(name, default, min, max)
float getFloat(name, default, min, max)
boolean getBoolean(name, default)
String getString(name, default)
<T extends Enum<T>> T getEnum(name, Class<T> enumClass, T default)

(I think I got the generics on that last one right.)

Basically each method knows how to handle parsing of the string value from the config file and to handle errors and to return the default value if appropriate. Range checking for the numeric values is probably sufficient. You might want to have overloads that omit the range values, which would be equivalent to providing a range of Integer.MIN_VALUE, Integer.MAX_VALUE. An Enum is a type-safe way of validating a string against a fixed set of strings.

There are some things this doesn't handle, such as multiple values, values that are interrelated, dynamic table lookups, etc. You could write specialized parsing and validation routines for these, but if this gets too complicated, I'd start to question whether you're trying to do too much with a config file.

Storage Format

Java properties files seem fine for storing individual key-value pairs, and they support the types of values I described above pretty well. You could also consider other formats such as XML or JSON, but these are probably overkill unless you have nested or repeated data. At that point it seems way beyond a config file....

Telastyn mentioned serialized objects. This is a possibility, although serialization does have its difficulties. It's binary, not text, so it's hard to see and edit the values. You have to deal with serialization compatibility. If values are missing from the serialized input (e.g., you added a field to the Config class and you're reading an old serialized form of it), the new fields are initialized to null/zero. You have to write logic to determine whether to fill in some other default value. But does a zero indicate absence of a config value, or was it specified to be zero? Now you have to debug this logic. Finally (not sure if this is a concern) you still may need to validate values in the serialized object stream. It's possible (though inconvenient) for a malicious user to modify a serialized object stream undetectably.

I'd say to stick with properties if at all possible.

Answer 3

How I've done it:

Initialize everything to default values.

Parse the file, storing the values as you go. The places being set are responsible for ensuring the values are acceptable, bad values are ignored (and thus retain the default value.)

Answer 4

Are there other solutions to this kind of problem?

If all you need is a simple configuration, I like to make a plain old class for it. It initializes the defaults, and can be loaded from file by the app via the built in serialization classes. The app then passes it around to stuff that needs it. No mussing about with parsing or conversions, no screwing around with config strings, no casting garbage. And it makes the configuration way easier to use for in-code scenarios where it needs to be saved/loaded from server or as presets, and way easier to use in your unit tests.

Answer 5

At least in .NET, you can pretty easily create your own strongly-typed configuration objects -- see this MSDN article for a quick example.

Protip: wrap your config class in an interface and let your application talk to that. Makes it easy to inject fake configuration for tests or for profit.