Well, you would of course not make it private then but "default". This
means it's better hidden than protected, but in your own package, you
(as the designer of that package&class) can still derive from it.

My impression is, that this is the only (principially) relevant argument
for Singleton-classes. The other ones failed to convince me just like you.
But others' mileage may vary...

This also might help
http://code.google.com/p/google-singleton-detector/wiki/WhySingletonsAreControversial

For me, the key issue is one you do not mention, what happens if you
find out it needs to be a non-singleton, for example to support more
flexible testing.

If you use static, you need to change every use of any method in the
class. If you use a singleton, you at most have to change getInstance
calls. Many of those may not need to be changed if there is a default
instance returned by the parameterless getInstance method.

Patricia

Which breaks as soon as two different instances need different state at the
same time.

All-static-method classes get away with it by /not/ maintaining any state.
It's a pattern for stateless methods.

Hi,

No worries, I can't understand most blogs either - mainly because most
blogs suck.

The singleton pattern is useful to ensure that 'only one instance of
that class' is ever created and available during the running of your
application. Its almost irrelevant that it holds member variables and
their state, as this is more of a value added capability.

The most common implementation of a singleton in Java uses a factory
method to return the instance.

class MySingleton {
  private static MySingleton instance = new MySingleton();
  //private constructor here....

  public MySingleton getInstance() { return instance; }
}

This ensures that only one instance of MySingleton Class is avaiable
to the application at runtime.

Then these singletons then tend to be given member variables to store
that are needed through out the application. e.g.  property file
values loaded into it, main frame of the UI, etc....

For this kind of ability, a singleton is a natural (though not
necessarily nice) choice to make.

A static method is only useful for utility methods (like the
getInstance factory method above) where they dont need to access
instance variables or maintain state.

Yes its true you could maintain state in static variables which static
methods call, but then you have basically create a class that can't be
used like any other class - polymorphically.

There is a middle ground though.

Its called the MonoState pattern.  This is where you have a call with
only static member variables, all methods are still not static
methods.  This means evey use of the class has to create an instance
of it, but every instance shares the same static member variable
state. This hybrid pattern allows the benefits of polymorphism to
continue, whilst allowing the system wide state of the member
variables. Its useful if you are doing a lot of JUnit tests, where you
need to override the monostate behaviour for your tests.

That said...the whole issue is moot...  Basically if you need only one
instance of the class... then just create one, not two.

The biggest problem with Singletons, Static methods, Monostates etc...
is that people are lazy.  They can't think how to designt he system so
that the dont have to pass around all over the place, the single
instance of a class they created, so they go with a singleton, not
because they actually need a singleton...just because its easier.  Its
less coding and requires less thinking.

Best regards

Andrew