title: Application settings design approach
body: <p>Assume there's a complex application where we store and retrieve a set of application settings.</p>
  
  <p>Application settings used into many application classes and there are two ways to solve this task.</p>
  
  <p>The first one. Declare ApplicationSettings as singleton.</p>
  
  <pre><code>public class ApplicationSettings {
  
      private static final ApplicationSettings instance = new ApplicationSettings();
  
      public static ApplicationSettings getInstance() {
          return instance;
      }
  
  
      // ... public methods to set and retrieve settings information, save settings, etc.
  
  
      private ApplicationSettings() {
  
          // loading the application settings in the private constructor
      }
  }
  </code></pre>
  
  <p>And we have an <code>Application</code> class (and many other classes), where we use application settings.</p>
  
  <pre><code>public class Application {
  
      public Application() {
  
          // .... initialization code 
      }
  
  
      public void doSomething() {
  
          ApplicationSettings applicationSettings = ApplicationSettings.getInstance();
  
          someMethod1(applicationSettings.getSetting(ApplicationSettings.SETTING_SOME_KEY1));     
          someMethod2(applicationSettings.getSetting(ApplicationSettings.SETTING_SOME_KEY2));     
  
          // etc
      }
  }
  </code></pre>
  
  <p>It may look convenient, but use of singletons has some serious drawbacks, for instance, singleton classes are hard to test. And use of singleton classes makes classes less flexible and manageable.</p>
  
  <p>As an option, to avoid use of singletons, we declare <code>ApplicationSettings</code> as a regular class, not singleton. And pass <code>ApplicationSettings</code> instance as a parameter to constructors of classes which are using <code>ApplicationSettings</code> for internal activities.</p>
  
  <p>The second way:</p>
  
  <pre><code>public interface ApplicationSettingsInterface {
  
      // ... public methods to set and retrieve settings information, save settings, etc.
  
  }
  
  
  public class ApplicationSettings implements ApplicationSettingsInterface {
  
  
      private ApplicationSettings() {
  
          // loading the application settings in the private constructor
      }
  
  
      // ... public methods to set and retrieve settings information, save settings, etc.
  
  }
  
  
  
  public class Application {
  
      private final ApplicationSettingsInterface applicationSettings;
  
  
      public Application(ApplicationSettingsInterface applicationSettings) {
  
          this.applicationSettings = applicationSettings;
  
          // .... initialization code 
      }
  
  
      public void doSomething() {
  
          someMethod1(applicationSettings.getSetting(ApplicationSettings.SETTING_SOME_KEY1));     
          someMethod2(applicationSettings.getSetting(ApplicationSettings.SETTING_SOME_KEY2));     
  
          // etc
      }
  }
  </code></pre>
  
  <p>I believe that the second way is more flexible and produces more manageable code than the first way with the singleton.</p>
  
  <p>My question: the second way assumes that we need to store reference to application settings into every class instance that uses app. settings and gets app. settings object as a constructor parameter. </p>
  
  <p>Is it ok to have those application settings references stored into <strong>many</strong> object instances or there's a better, third way to deal with this task?</p>
  
  <p>Thank you.</p>