Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 ?

share|improve this question
I do. Works fine for me. – LachlanB Feb 7 '13 at 5:18
Because the Singleton pattern came from GOF and GOF is cool... /s – Evan Plaice Feb 7 '13 at 5:52
up vote 7 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.