Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Design Pattern for one-time loaded configuration properties? [closed]

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?

like image 977
Stefan Kendall Avatar asked Mar 23 '10 20:03

Stefan Kendall


People also ask

What is Singleton factory and builder design pattern?

Singleton pattern is the simplest design pattern and the factory method is supposed to be a common design pattern that is widely used. The builder pattern is used to construct complex objects and is mostly used in developing complex applications.

What design pattern should you think of when you want to hide how you construct a complex object?

What design pattern should you think of when you want to hide how you construct a complex object? Give only one pattern. Which design pattern would you use when you want a client to create a new object without explicitly specifying the class of the new object? Give only one pattern.

What are the types of factory pattern?

the abstract factory pattern, the static factory method, the simple factory (also called factory).

Which one of the design pattern comes under the creational design pattern?

Creational design patterns are the Factory Method, Abstract Factory, Builder, Singleton, Object Pool, and Prototype.


3 Answers

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.

like image 191
noah Avatar answered Oct 11 '22 22:10

noah


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
    }
}
like image 21
invkesg Avatar answered Oct 11 '22 21:10

invkesg


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.

like image 21
weekens Avatar answered Oct 11 '22 21:10

weekens