Is this a good use of the Singleton pattern?

Question

I make a lot of "design your own ____" applications.
What I do is I make a singleton class to hold all the customizations the user has chosen. For example: When you select you want something green, it updates a getter/setter in the singleton to be green. Then when the application needs to know what color was selected it gets the info from the same getter/setter.
The way I used to do this was by storing the information in the UI (just checking what color was selected from the drop-down).
After reading about MVC (I still dont "fully" understand MVC) I know now that is completely wrong and thats why I abstracted it to the singleton class that holds all that.

Now I am wondering if that is a bad idea too? if so how should I be doing it?

Thanks.

Answer 1

I'd say that is not really what the Singleton pattern was intended for. It is a very misunderstood pattern and the most common reason people use it seems to be that it is easy to access since they are often static. What really is happening is that you have a configuration problem that you are trying to get around through a static singleton that can easily be access throughout the application. A 'proper' use would be when trying to control access to a resource that is truly limited.

If you think of it probably really doesnt make sense to have only one universal 'configuration' for an application. It makes a lot more sense to have several but perhaps only one is ever in use at one time.

-Edit- Instead of using a Singleton that can be accessed statically consider using Dependency Injection or Inversion of Control.

Answer 2

I, being a Service Layer guy (though I have my own vision of a service layer), would recommend doing some IoC and moving all customization logic to a separate service (AmbienceService or something). Thus, in your presenter you'll do (C#-style pseudocode):

viewModel.HeaderColor = ServiceLocator.Resolve<AmbienceService>().HeaderColor;

Answer 3

I'm not completely sure what your question is but here is what I'm making of it.

Your application has a UI that lets the user select a bunch of parameters (e.g. a drop down with a set of colors. One of which is the color green.)

Later on (for example after closing down the application and restarting it) the chosen value needs to be loaded again.

If this is what your specific question is about, I don't really think this has anything to do with the singleton pattern per se. I think what you want is a config file (app.config for applications and web.config for web applications). With the ConfiguratoinManager class you can easely acces these.

Answer 4

Singletons limit the number of instances to one by design. In your case, why have you decided that you MUST only have one instance? What if you want multiple configurations? Multiple instances, each representing a different configuration, is not possible with your design.

Answer 5

I assume you are talking about something like a car configurator - select paint, engine, rims, and all the other stuff.

In this case I would not use a singleton. Not because it does not work, but because it seems semanticaly wrong. A singleton implies there is only a single state. But your application could have two windows - something like two documents. With a singleton you cannot modify both documents independently because they share their state. So you see, it really should not be a singleton.

Answer 6

The answer to your question may have a lot to do with your current environment. For instance, in Java runtime properties are provided via System.getProperties, etc. Windows has its registry.

Have you thought of solutions like using Contexts to transfer state? Do you really need global properties? Can your properties be changed at runtime? Will you have multiple threads potentially modifying the same properties? These are all things to consider in a design.

Personally, I normally just opt for whatever seems to be the convention for the environment under which I'm working. From your last question, it sounds like you are working with ActionScript, is there a convention already existing for it?

Answer 7

That's not the pattern you should be using. I think you should try a state pattern instead. Singleton is for when you need access to a limited resource from many different places.

Like opening and reading a configuration file. Instead of different classes reading the same file they go through a class that does only that. What you need is when the user changes a setting the system needs to be notified that something has been changed.

But this really depends on the language you are using. As far as I know only java has a onNotify() method. But I could be wrong.

Answer 8

Remember that a Singleton is basically a global variable, and has all the same problems. For example:

• Every class potentially has a dependency on the singleton (and anything that the singleton itself depends on). But that dependency isn't made explicit through the values you pass around, so it's impossible to detect.
• Since you can write to it from anywhere in your program, you risk changing it any time you call a function. So you can never completely rely on its value.

I know it's a pain to pass an object around to every part of the program that needs it. But this will eventually result in a better design.

• It will force you to reduce the number of classes that depend on your data object.
• It will make refactoring easier and more predictable, because you'll be confident that your object isn't being changed behind your back.