Singleton v/s class with static members & methods

[Ranjan Maheshwari]

Why would one ever require one and only one instance? Same purpose can be achieved using classes with static member variables and static methods.

[fred rosenberger]

because static variables are not thread safe.

[Mike Simmons]

I would think that static variables are just as thread-safe (or not) as instance variables in a singleton. If they're protected, they're safe. If they aren't protected, they aren't safe. And of course if there's no mutable data, both designs are safe.

[Jeff Verdegan]

Mike Simmons wrote:I would think that static variables are just as thread-safe (or not) as instance variables in a singleton.

They are, whether in a singleton or in a "normal" class.

[Mike Simmons]

Sorry, "I would think" was just my attempt at being politely understated. I'm well aware it's true;

[Jeff Verdegan]

Ranjan Maheshwari wrote:Why would one ever require one and only one instance? Same purpose can be achieved using classes with static member variables and static methods.

It's true that the Singleton Pattern is overused and abused. However assuming you have a valid reason to use that modle, there is a difference between a true singleton object and a non-instantiable class full of only static methods: Polymorphism.

If you go the once-instantiable-object route, you can have your singleton implement one or more interfaces, and you can easily swap different implementations in and out without code changes, and you can use a mock implementation for testing. You can't do this with a class full of static methods, since there's no runtime polymorphism.

Additionally, people are more used to seeing classes of static methods as utility or helper classes with no state, and singletons as once-instantiated objects. So if you use a class full of statics, it makes your code less clear and violates the Principle Of Least Surprise.

[Ranjan Maheshwari]

Jeff Verdegan wrote: there is a difference between a true singleton object and a non-instantiable class full of only static methods: Polymorphism.

Can someone give me examples from Real life scenarios where Singleton objects will take part in polymorphism?

Jeff Verdegan wrote: the Principle Of Least Surprise.

What's the Principle Of Least Surprise?

[Paul Clapham]

Ranjan Maheshwari wrote:

Jeff Verdegan wrote: the Principle Of Least Surprise.

What's the Principle Of Least Surprise?

To find the answer to that I strongly recommend you type those very words into your favourite internet search engine. You'll find a number of well-written pages which will provide a much better answer than the answer that somebody here will throw together in 30 seconds or less.

[Jeff Verdegan]

Ranjan Maheshwari wrote:

Jeff Verdegan wrote: there is a difference between a true singleton object and a non-instantiable class full of only static methods: Polymorphism.

Can someone give me examples from Real life scenarios where Singleton objects will take part in polymorphism?

Off the top of my head, no I cannot come up with any specific cases where I've done that, and I'm not interested in trying to invent one. However, I've given you examples of the kinds of situations where you might want that, as well as the reason of general convention. You now have the tools to make an informed decision when you're faced with this choice. I will only add that I cannot think of one single real benefit to using a class full of statics when we want singleton-like behavior.

[Mike Simmons]

I'm not sure I've ever seen an advantage to using a true absolute Singleton, where there is only one instance ever. However I've often seen benefit in things that are usually restricted to be singletons, at production time, but can be replaced with mock objects during testing. Using instance methods allows you to take advantage of overriding and replace behavior when necessary; using static methods prevents this.

Additionally having a singleton is more flexible - you may not be sure whether you need or want a singleton, or multiple instances. And your clients may not know or care - they just want an API they can use. If you use a singleton, you can replace it with multiple instances later if you want to, and the client need never know or care. But if you want to replace static methods with instance methods on multiple instances, the client will be forced to change their code to match your changing API.

[James Boswell]

It is also referred to as Principle of least astonishment.

[James Boswell]

But if you want to replace static methods with instance methods on multiple instances, the client will be forced to change their code to match your changing API.

Excellent example Mike.