Design Pattern for one-time loaded configuration p

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

I'm often faced with the problem of storing, in memory, a few (possibly complex) configuration settings loaded from files on the filesystem. I'm wondering if there's a better way to architect a pattern to this problem, however, than what I've been using.

Essentially, my current solution involves three steps.

1. Build a singleton. Since data is persistent and guaranteed not to change through the runtime of the application, only one object instance should ever be needed.

2. When the first request for the object is made, create the object and read in from a file.

3. Expose data with getters.

This has the effect that a lot of my code looks like this: MyConfiguration.getInstance().getWeightOfBomb(), which looks rather odd to me.

Is there a better way to handle this in a more semantic fashion?

Answer 1

Additional proposal for noah's answer.

If it is inconvenient for you to write a method for each configuration parameter, then you could use enum for that. Here is what I mean:

public class Configuration {

private final Properties properties;

public enum Parameter {
    MY_PARAMETER1("my.parameter1", "value1"),
    MY_PARAMETER2("my.parameter2", "value2");

    private final String name;
    private final String defaultValue;

    private Parameter(String name, String defaultValue) {
        this.name = name;
        this.defaultValue = defaultValue;
    }

    private String getName() {
        return name;
    }

    private String getDefaultValue() {
        return defaultValue;
    }
}


public Configuration(Properties properties) {
    this.properties = (Properties)properties.clone();
}

//single method for every configuration parameter
public String get(Parameter param) {
    return properties.getProperty(param.getName(), param.getDefaultValue());
}

}

After that, if you have a new configuration parameter, all you need to do is to add a new enum entry.

You can also extract an interface from Configuration class, of course, moving enum outside.

Answer 2

You could create an interface to represent the configuration:

public interface Config {
    interface Key {}
    String get(Key key);
    String get(Key key, String defaultValue);
}

And a singleton implementation:

public enum MyConfig implements Config {
    INSTANCE("/config.properties");
    private final Properties config;

    MyConfig(String path) {
        config = new Properties();
        try {
            config.load(this.getClass().getResourceAsStream(path));
        } catch (IOException | NullPointerException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    @Override
    public String get(Config.Key key){
        return config.getProperty(key.toString());
    }

    @Override
    public String get(Config.Key key, String defaultValue) {
        return config.getProperty(key.toString(), defaultValue);
    }

    public enum Key implements Config.Key {
        PROXY_HOST("proxy.host"),
        PROXY_PORT("proxy.port");
        private final String name;

        Key(String name) { this.name = name; }    
        @Override
        public String toString() { return name; }
    }
}

And then inject the configuration in your classes:

public class SomeClass  {
    private final Config config;

    public SomeClass(Config config) {
        this.config = config;
    }

    public void someMethod() {
        String host = config.get(Key.PROXY_HOST);
        String port = config.get(Key.PROXY_PORT, "8080");
        // Do something
    }
}

Answer 3

Dependency Injection. You don't necessarily have to use a DI framework like Spring or Guice but you really want to avoid littering your code with singletons. You can still use a singleton in the implementation, but there is no reason the rest of your code needs to know that it is a singleton. Singletons are huge pain when unit testing and refactoring. Let your code reference an interface instead. e.g.,

 interface MyConfig {
     double getWeightOfBomb();
 }

 class SomeClass {
    private MyConfig myConfig;

    public void doSomething() {
       myConfig.getWeightOfBomb();
    }
 }

 class MyConfigImpl implements MyConfig {
     public double getWeightOfBomb() {           
          return MyConfiguration.getInstance().getWeightOfBomb(); 
     }
 }

If you use a DI framework, just setup you classes to have your MyConfig implementation injected. If you don't, then the laziest approach that still has all the benefits is to do something like:

 class SomeClass {
    private MyConfig myConfig = new MyConfigImpl();        
 }

Really it's up to you. The important thing is that you can replace myConfig on a per instance basis when you later realize that you need the behavior to vary and/or for unit testing.