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.

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.

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.

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.

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)