[Tiomaidh]

    public class Singleton {
        private static Singleton self = null;
        private Singleton() {
            //...
        }
        public static Singleton getInstance() {
            if(self == null) {
                self = new Singleton();
            }
            return self;
        }
        ...
    }

So at any point in your code you can call Singleton.getInstance() to have access to the same Singleton object. So it's effectively the same thing as a global variable.

Edit: Added `static' to be more correct.

[billjedi]

private Singleton self = null; is wrong.

It has to be:

private static Singleton self = null;

[dteoh]

Enum version:

    public enum Singleton {
        INSTANCE;
    }

Guaranteed against multiple instantiation.

Edit: the class version of the singleton example should also be made final, or I could just extend your class and therefore bypass your singleton restriction.

[SoftwareMaven]

Not with a private constructor.

[qntm]

What are the advantages of instantiating the Singleton object in multiple different locations rather than, for example, using the Singleton class itself as an object with various static attributes and methods?

[antrix]

In addition to what johnyzee says, in Java at least, a class with just static methods can't _implement_ any Interfaces.

[Almaviva]

One benefit is that you can replace the singleton instance with a mock or subclass for testing if you need to.

[misterbee]

Nothing. Both are the same bug.

[MatthewPhillips]

Not thread safe.

[johnyzee]

Thread safety is the same whether you use a static instance or plain static methods. In fact with all static members you don't have to worry about synchronizing initialization of the singleton object which is often done wrong.

The only reason to use a singleton over static members is that it feels like OO. I suppose it also makes it easier to replace the singleton with a 'multiton' at some point in the future which somewhat justifies it.

[MatthewPhillips]

There isn't a clean way to initialize all of your static properties doing it that way. If you're using a language that has accessors you can call a private init method, but you have to do it for all of the properties. Or you can just use methods, but again you have to remember to call init at the beginning of them all. Or you could have a public init() and just remember to call it when your application first launches. Using a singleton is a natural way to have an entry point towards initialization. You can also have the best of both worlds by using static properties/methods that point to the singleton version.

In Java/C# you can use a nested class to ensure thread safety and cheat towards having your static methods. For example:

private int Foo() { }

public static int Foo() { return _instance.Foo(); }

private static FooBar _instance { return Nested.instance; }

FooBar() { // Initialize here! }

class Nested {

static Nested() { }

internal static readonly FooBar instance = new FooBar();

}

[smanek]

and that isn't thread safe lazy initialization either ;-)

it's surprisingly tricky to get lazy init right.