views:

423

answers:

5

If a class implements a singleton pattern, should all the variables be declared static?

Is there any reason they shouldn't be declared static? Does it make a difference?

+8  A: 

No. The singleton pattern just means that a single instance is the only instance -- it does not mean "make everything statically accessible".

The singleton pattern gives you all the benefits of a "single instance", without sacrificing the ability to test and refactor your code.

Edit:

The point I'm trying to make is that there is a difference between how functionality should be consumed (which depends on context), and how functionality should be initialized.

It may be appropriate that in most cases your object will only ever have a single instance (for example, in your final production system). But there are also other contexts (like testing) that are made much more difficult if you force it to be the only choice.

Also, making something static has more significant implications than just "only one instance of my class should be accessible" -- which is usually the intention.

Further, in software I've worked on, the initialization and lifecycle of objects is often controlled by someone else (I'm talking about DI here) -- and making something static really doesn't help here.

Nader Shirazie
Strictly speaking the singleton pattern allows you to limit the number of instances so it may be zero or more (zero if it is lazily intialized). It is common for it to be one. If you were to ever want it to be 2 or more making things static would make it harder.
TofuBeer
@TofuBeer, surely it wouldn't be a singleton if you were allowed two. Wouldn't that be a doubleton? :-)
paxdiablo
+4  A: 

In one common singleton pattern, you do not use statics. You code the class to use ordinary fields, you initialize in the constructor, and then you arrange to execute new MyClass() once, storing the results in some static place.

bmargulies
+1  A: 

You can do this (not necessarily should). But, even for a singleton, I tend to make all the variables object-level rather than class-level because:

  • I may at some point decide a singleton was a bad idea for that class and having class-level variables will make refactoring harder.
  • With object-level variables, they only come into existence when you instantiate the singleton. With class-level, they're always there.

Bottom line: I've never been able to think of a disadvantage to having them as object-level so that's how I do it. The above two disadvantages to class-level may be minuscule but they're there. It probably comes down to personal preference in the end.

paxdiablo
+1. Technically static fields are not "always there" - they "come into existence" when class is loaded.
ChssPly76
+3  A: 

No, the only thing that is usually static is the reference to the singleton itself (and there are other ways to store that reference, too, such as JNDI or dependency injection containers).

The reason for not declaring fields as static (even though in a singleton pattern you will need only one instance of them) is that this gives you the flexibility to create another, slightly different instance of the normally singleton class. You may want to do that in special situations, such as for testing.

Even if you do not (think you) need that flexibility, there is no reason to give it up. Declaring a field as static has no benefits that you would lose.

Thilo
+1 for provide single instance access where appropriate, without giving up the benefits of "multiple instance", which is what happens when you make everything static.
Nader Shirazie
A: 

You can read up on how (one possible way) to create a singleton in Java here:

Wikibooks Design Patterns: Java Singleton

Basically you don't need (nor should) make all things in the class static just because you intend to use something as a singleton. There are several reasons

  • Check answers from paxdiablo and Thilo
  • Also don't forget make it all static doesn't make it a singleton you would also need to remove every constructor (and make the default constructor private)
jitter
I don't know if it is necessary to make all constructors private. You can use the singleton pattern without enforcing that there can never be other uses for the class. Also, publicly visible constructors play nice with DI and such.
Thilo