What are some specific legitimate uses for singlet

Question

This question already has answers here:

Closed 10 years ago.

Possible Duplicate:
On Design Patterns: When to use the Singleton?

This question is not about whether or not singletons are "considered harmful" in general. I just want to know, from your experience, what are some SPECIFIC SITUATIONS in which singletons seem to work well.

EDIT: Please, if you want to discuss the appropriateness and/or evilness of singletons in general, there are aleady exising questions: 137975, 11831

Oops! I've just discovered that my question has already been asked here: On Design Patterns: When to use the Singleton?

Answer 1

Generating a sequence of random numbers - the random generator should be unique, not instantiated for each use. One might want to implement this as a thread-level singleton; however, a singleton for the whole process is still appropriate in this case.

Answer 2

I just worked really hard getting rid of Singletons in the current project I am working on. They have a smell, but sometimes are very difficult to avoid.

My situation was that I had an API which constructed singleton objects for handling management functions such as Security, Configuration, etc. The API used EntityFramework and also pulled in PlugIns (using MEF). Because the construction of these classes was not always performed by my code (particularly for EF entities), it was not always possible to inject these into biz objects elegantly. So I used singletons, which can be accessed anywhere within a project subject tot heir scope.

Answer 3

Master server takes requests from clients, and passes these requests off to a subordinate process. The subordinate process may use a singleton for communicating with the master server.

Answer 4

• Logging.

• Finding localized string resources e.g. Strings.get("CONFIRM_DELETE").

Both of these things are not details that should be exposed in the public interface of your objects, so it makes sense to use a singleton here.

Answer 5

• When your domain specifies that there only exists one unique instance of something you're modelling

---

I still believe singletons should be avoided (in Java at least).

There's two different things to consider: the concept and the mechanism for enforcing the Singleton pattern.

The concept of Singletons have many uses, logging, configuration, not to mention when the domain you're working actually has things where there is ever only one instance of them and you wish to model that. I.e. a company only has a single expenses processing office and sending expense forms to an invalid office is wrong, the office is in reality a singleton. The concept of a singleton has many legitimate uses.

However, it's usually the mechanism that causes the problem. In Java we enforce an object can't be constructed by declaring the constructor private, the problem with this is we also have to provide a global point of access to the instance through the concrete class. This couples everything in your application to that concrete class, which can't be changed at run-time, or mocked in unit testing. It's this mechanism which is considered evil - particularly in terms of testability.

If the concept of Singletons can be separated from the poor mechanisms, they would not be so evil. One example, I can think of is the @Singleton scope available in Guice. In the context of Guice, it guarantees one instance, but it doesn't achieve this with the evil private constructor/global point of access mechanism.

Answer 6

We basically use them for two things: logging, and configuration. Both assume that the app has a central config and a central logfile, not always valid but in most of our code it is. We also use them on occasion for certain factory classes or cache classes we want to make sure we're not duplicating key metadata.