Is a “master preferences” class a good idea?

Question

I have a class that manages user preferences for a large software project. Any class in the project that may need to set or retrieve a user preference from a persistent store i

Answer 1

I deleted my first answer since I misunderstood what the author was asking.

To actually address the actual question--it feels like your desire to place preferences (and the calculation of the default values) with the code that uses them makes sense.

Could you meet both requirements by using a preferences container class for each area that follows a pattern for that area, but having it register with a "Global" preference object collection?

Your global collection could do things like iterate over each set of preferences and reset it to defaults but your preferences themselves would still be locally defined and maintained so that it doesn't spider out into other parts of the code.

The only problem I can see is that if you allow the preference object to register itself when instantiated, you run the risk of trying to "reset to defaults" with some of the preferences not instantiated yet.

I suppose this could be fixed by having the main "preference" class instantiate all the others, then any piece of code could retrieve it's local preference object from the central one though a static getter.

This seems to be a lot like how some loggers work. There is a central mechanism for maintaining log levels, output streams and such, but each class has it's own instance of a "log" method and logs to it.

I hope this was more on target. Oh, I also agree with the accepted answer, don't ever make all your methods public static, always use a getter--you'll be glad you did some day.