设置包装器类是一种好习惯吗？

Question

I was thinking how to wrap all my settings and for example I use once or even more. Let's think a bit abstractive.

class WholeApplicationSettingsInHere{
    private static boolean setting1, setting2;

    WholeApplicationSettingsInHere(){set defaults}

    public static boolean getSetting1(){return setting1}
    public static void setSetting1(setting1){set setting1}

    public static boolean getSetting2(){return setting2}
    public static void setSetting2(setting2){set setting2}

    ...
}

class One(){
/*No fields in here, except private fields*/
    methodOne(){use variables from WholeApplicationSettingsInHere class}
    methodTwo(){}
}

class Two(){
/*No fields in here, except private fields*/
    methodOne(){use variables from WholeApplicationSettingsInHere class}
    methodTwo(){}
}

My question is if it will be a good practice to do things that way?

Answer 1

You should the PreferenceManager and SharedPreferences to store and retrieve user preferences. Using static booleans in a class doesn't really seem like a great idea.

Just create a simple class with your methods, for example:

public class PreferencesHelper {

    private PreferencesHelper() {} // No instantiation

    public static boolean getSetting1(Context context) {
        return PreferenceManager.getDefaultSharedPreferences(context).getBoolean(PREFERENCE_KEY, defaultValue);
    }

    public static void setSetting1(Context context, boolean value) {
       Editor editor = PreferenceManager.getDefaultSharedPreferences(context).edit();
       editor.putBoolean(PREFERENCE_KEY, value);
       editor.apply();
    }

}

And finally, to answer your question: Yes, it can be good practice, if you do something like the above-mentioned code. By doing so, you make it impossible to have preference keys scattered across your application, and it makes your code easier to read.

Having said that, if you're ever in a situation where you need to set multiple preferences at once, it's a bit of a waste having to call setSetting1() , setSetting2() , setSetting3() , etc., as you're recreating objects over and over again. In such cases, simply get the Edtior object, put all your changes, and apply the changes.

Answer 2

It's pretty hard to answer "is this a good practice" because there isn't one definitive answer. It depends entirely on your context. You might want to provide an MCVE that more accurately reflects exactly what you're doing.

I will say that making those variables and methods static is a pretty horrible idea- what happens down the road if you want two instances of your settings class?

And before you say "I'll only ever need one instance of the settings"- you can't know that ahead of time. This is a misuse of the static keyword.

And at that point- why not just use an instance of the Properties class?