Design Pattern for one-time loaded configuration properties?

Question

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

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.