Q:

Why don't we use a class and its static members to do what a singleton does?

In Java,C++,Objective C, C#, and all other similar OOP languages,
Why don't we use a class with static methods and vars instead of going through a singleton syntax having to deal with various scenarios ?

A:

This question has already be answered here

The big difference between a singleton and a bunch of static methods is that singletons can implement interfaces (or derive from useful base classes, although that's less common IME), so you can pass around the singleton as if it were "just another" implementation.

A:

First of all, let me say that I'm not a fan of either of these ideas -- global variables create a bevvy of problems regardless of whether they come in design pattern packaging or not.
That said, a singleton is (generally) externally instance based with the exception of its static Instance() method, meaning that you can participate to some degree in runtime polymorphism.  In other words, a singleton can implement an interface, inherit from some other class, or have another class inherit from it (I seriously don't recommend this last one).  Static methods are entirely procedural in nature so you can't do any of these object-oriented things with them.
The main advantage of singleton, as far as I'm concerned, is that it's somewhat easier to factor toward a better design if you're starting with a singleton than if you're starting with pure static classes that house state.  With the latter approach, your application architecture is about as flexible as a diamond and with singletons, its as flexible as, say, steel.  The singleton is slightly less bad, from a flexibility standpoint, and also slightly easier to fix.
There is another pattern, called monostate, in which all instances share internal static state but expose only instance methods.  If you've just gotta have your global variables, this is a nice way to prevent them from creating the hidden dependencies between your classes that tend to make singletons and static classes with state such a maintenance headache.

A:

For me the big difference is that a singleton is far more flexible.
I can use the getInstance() method as a factory. So if I want I can change the class to return a new instance every time instead of a single instance all the time if I find out that it is needed by my application.
If I want to do this with a class that only has static methods I have to refactor the whole application.
Also the getInstance() method can return another implementation (a subclass of the singleton) so I can change the implementation without changing my application.
BTW I also use sometimes classes with static methods if I'm sure that I don't need the above features.

