2

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?

rouble
  • 16,364
  • 16
  • 107
  • 102
  • 1
    Firstly, have you considered not using Singleton Pattern at all? It is well known as a anti-pattern in object-oriented programming. – nandokakimoto Nov 20 '09 at 00:44
  • 4
    I've never agreed that the singleton pattern is a bad one. Using it as a 'god' object is not a good idea, but it has its place. – paxdiablo Nov 20 '09 at 00:45
  • There are very few places where a singleton makes good sense -- string externalization is about the only one I see with any regularity, and even then, most popular platforms today provide libraries or language features that better encapsulate that use-case. – Cory Petosky Nov 20 '09 at 00:51
  • 1
    In many SOA applications, singletons are very prevalent -- though they may be "behind the scenes". – Nader Shirazie Nov 20 '09 at 00:59
  • Well, you may find bad references about singletons here (http://code.google.com/p/google-singleton-detector/wiki/WhySingletonsAreControversial) and here (http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons/138012#138012). – nandokakimoto Nov 20 '09 at 01:23
  • Both those links provide discussions as to the pros and cons of singletons. Neither says that it is inherently bad ... just that you should be careful when you use the pattern. – Nader Shirazie Nov 20 '09 at 03:13
  • @Nader: http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html , http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/ and http://misko.hevery.com/2008/08/25/root-cause-of-singletons/ – matt b Nov 20 '09 at 04:44
  • @matt - obviously I'm doing a horrible job of making my point, and maybe I've been making the wrong point. Your last link is very much along the lines that I'm thinking. If a global variable is the _only_ way to access your class, then you are in for a headache - and if that's what the "Singleton" pattern requires, then yes, I agree its mostly a bad idea (though even then there are uses, eg logging), for precisely the reasons you're discussing (hides dependencies/relationships, makes testing/refactoring hard, etc). – Nader Shirazie Nov 20 '09 at 05:39

5 Answers5

12

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
  • 10,736
  • 2
  • 37
  • 43
  • 1
    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 Nov 20 '09 at 03:14
  • @TofuBeer, surely it wouldn't be a singleton if you were allowed two. Wouldn't that be a doubleton? :-) – paxdiablo Nov 20 '09 at 13:28
4

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
  • 97,814
  • 39
  • 186
  • 310
3

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
  • 257,207
  • 101
  • 511
  • 656
  • +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 Nov 20 '09 at 00:47
1

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
  • 854,327
  • 234
  • 1,573
  • 1,953
  • +1. Technically static fields are not "always there" - they "come into existence" when class is loaded. – ChssPly76 Nov 20 '09 at 00:44
0

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
  • 53,475
  • 11
  • 111
  • 124
  • 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 Nov 20 '09 at 01:33