When would it be imperative to use Singleton

[manish ahuja]

Hi All


When would it be imperative to use the Singleton design pattern. Can someone just list a few real life scenarios where Singleton had to be there


Rgrds
Manish

[Lasse Koskela]

I have honestly not met such a situation where the use of the SingletonPattern would have been required.

[Alexandru Popescu]

Singleton usage is best suited for situations when you need to have full control on the number of instances of a class that are available at a specified moment.
For more details you can consult GoF. Martin Fowler talks a little about it too.

./pope

[Alexandru Popescu]

Originally posted by Lasse Koskela:
I have honestly not met such a situation where the use of the SingletonPattern would have been required.

Hibernate Session management inside a container is a very good example. I will update the post when I will find out the real link
Here it is (I should stop head banging)

./pope
[ November 18, 2004: Message edited by: Ali Pope ]

[Lasse Koskela]

Originally posted by Ali Pope:
Hibernate Session management inside a container is a very good example.

True. Although it's possible to just create a new SessionFactory every time someone needs one, it would be a performance killer to do so.

[Stan James]

Caches, pools and stateful interfaces (connections) to other systems are a couple examples I use. Servlets are singletons to avoid the overhead of creating and garbage collecting huge numbers of instances. (Anybody know if the theory is backed up by performance measurements?)
[ November 18, 2004: Message edited by: Stan James ]

[Jayesh Lalwani]

Singleton Pattern is mostly useful when your real-life entity is a singleton.

For example, you have a multi-threaded app that communicates with an external server. In this case, it's better to have a Singleton class that handles the communication with the server. Not only do you put all your communication logic in one place, but you can also control the access to the server. For example, the Singleton can pool connections to the server, control the number of concurrent connections to the server etc, etc

[Jeanne Boyarsky]

I too use singletons for caching. However it is more for performance than being absolutely imperative.

[Sujatha Kumar]

"Any Class whose state does not change may also qualify as a Singleton",
The above point also may be considered for the usage of singleton.
[ November 18, 2004: Message edited by: Sujatha Kumar ]

[Ilja Preuss]

Originally posted by Jayesh Lalwani:
Singleton Pattern is mostly useful when your real-life entity is a singleton.

For example, you have a multi-threaded app that communicates with an external server.

That's actually one of the examples where I find using a Singleton to be a suboptimal solution. (I just picked it because it was the last in this thread - I'm not convinced by the other examples, either.)

The reason is that the "only one server" requirement is likely more of a temporary coincidence than an unchanging fact of life.

The problem actually is not the "guarantee only one instance" part of the Singletons' definition, but the global access point to that one instance.

When the business people after a year of development find out that now they'd actually prefer to have two servers, your whole code is likely to be build on the premise that there is only one, and that they can access it through the static methods of the Singleton. It's going to become a refactoring nightmare.

That's why I would prefer the Just Create One pattern - simply create the one instance of the server at a central place and *pass that instance around*, so that all the other objects don't know where it's coming from and how much of them might exist. As a nice side effect, that will also make unit testing your code much easier.

[Ilja Preuss]

Originally posted by Stan James:
Servlets are singletons to avoid the overhead of creating and garbage collecting huge numbers of instances.

Servlets aren't Singletons, but Just Create One's, aren't they?

[Stan James]

Yeah, Just Create One is a beter description. I never drew the distinction that Singleton required a software solution that forced a single instance. But the GoF intent and implementation sections both say "to ensure a class only has one instance" so I guess I needed a refresher.

GoF implementation also has a neat section on subclassing singletons. Quite a few discussions say the inability to subclass is a drawback to singleton. Refreshers all around, bartender!
[ November 20, 2004: Message edited by: Stan James ]

[Pho Tek]

Uncle Bob recently ranted against the use of Singletons.
[ November 21, 2004: Message edited by: Pho Tek ]

[Ilja Preuss]

Originally posted by Pho Tek:
Uncle Bob recently ranted against the use of Singletons.

And I think he has some very good points...