singleton class VS static class

I've been reading a little about the difference between using a
singleton pattern vs using a static class (ie all methods are static,
ctor is private, state is in static vars).

A lot of blogs show that there are differences between these two
approaches. I can't understand most of them. Any help would be appreciated.

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

---

Assertion found on web: "The Singleton pattern is useful when the object
itself needs to keep some state. If no such thing is needed, a static
method can do the job as well."

My POV: No, you can put a state in a static var and access it through
static methods.

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.

---

Flexibility of the factory mehod: You can simply create two subclasses,
MyDevelopmentSingleton and MyProductionSingleton, and let your
MySingleton.getinstance() function decide which to return.

My POV: If you declare you ctor private to enforce the singleton
pattern, you cannot subclass it. If you declare the ctor protected, is
it still a true singleton? Users can then create more than one object...

---

Assertion found on web: The main difference between static and Singleton
classes is that static classes don't ever get initialised.

My POV: I don't understand. What about static initializers?

---

So, in the end it's not clear for me why one should prefer the Singleton
pattern over the static class (should I?). I mean

SingletonClass.getInstance().setSomething(int a);
SingletonClass.getInstance().getSomething();

is quite quivalent to

StaticClass.setSomething(int a);
StaticClass.getSomething();

Any comments are welcome. Best regards
Phil

Best regards

Andrew

转载于:https://www.cnblogs.com/kamome/archive/2009/10/13/1582497.html