Assume there's a complex application where we store and retrieve a set of application settings.

Application settings used into many application classes and there are two ways to solve this task.

The first one. Declare ApplicationSettings as singleton.

```
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
    }
}

```

And we have an `Application` class (and many other classes), where we use application settings.

```
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
    }
}

```

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.

As an option, to avoid use of singletons, we declare `ApplicationSettings` as a regular class, not singleton. And pass `ApplicationSettings` instance as a parameter to constructors of classes which are using `ApplicationSettings` for internal activities.

The second way:

```
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
    }
}

```

I believe that the second way is more flexible and produces more manageable code than the first way with the singleton.

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. 

Is it ok to have those application settings references stored into **many** object instances or there's a better, third way to deal with this task?

Thank you.