Im reading on design patterns and found out that the use of singletons is discouraged. The project im working on at the moment has heavy use of singletons. One example is the state of the settings of the app is accessed and changed by a singleton called SettingsHandler. Upon first app creation SettingsHandler class is instantiated and it begins to load the settings values from shared preferences and saves the values in its local fields, afterwards from any point in code where needed you can call SettingsHandler.getInstance(context).getIsSettingXYEnabled() to get the status of an app setting, there are multiple places in the code where knowing the status of a setting is needed. Ofcourse you can also save the setting state by saving the value in the singleton fields first and then in shared preferences to be used at next app load.
My question is: if singleton is evil and bad, how do I make this work without it ? I know for sure that I need only 1 instance of the app settings class and I need access to it in many different places in code. For example I can create the instance once at application start and then just pass that reference around in code but that would be a big big mess since I will have to pass it as an argument to many many many constructors, so whats the alternative here so the code is cleaner ?
Aucun commentaire:
Enregistrer un commentaire