Is it good programming to have lots of singleton classes in a project?

I have a few classes in a project that should be created only once.

What is the best way to do that?,

1. They can be created as static object.
2. Can be created as singleton
3. Can be created as global.

What is the best design pattern to implement this?

I am thinking of creating all classes as singleton, but that would 开发者_运维知识库create lot of singletons. Is it good programming practice to have lot of singletons?

What are the pros and cons for using singletons?

Take a look at Steve Yegge's blog post about this - Singleton Considered Stupid

If they only need to be created once, that doesn't mandate they should be singletons.

• If X is a singleton, it's implied there is one instance.
• If X has one instance, that doesn't mean it should be a singleton.

Use a singleton if you require there be only one instance of the class, and that it be globally accessible. In your case, simply only needing one isn't reason enough. Globals are bad, singletons are glorified globals.

Most often, you don't need them. You'll see it a lot in bad code because of the very mentality: I only need one, that must mean I should make it singleton! (Wrong) For example, I've finished the technical design of the most powerful game engine I've ever done to date. It has 2 singletons, for memory and threading. A very large project, and I only have two!

More context would help us give you better information.

I suggest you look at some of the videos and articles that Miško Hevery of Google has done. First a video: "Clean Code Talks: Global State and Singletons" and his blog.

The general concensus is that Singletons are OK in a few rare instances, for example logging, but in most other situations you want to use dependency injection. Singletons make it harder to test your code and they hide dependencies so that your classes cannot be instantiated easily in isolation.

Singletons have a few problems -- they're hard to test, hard to replace, and hard to extend. There's usually a better way.

One of my favourite articles on the singleton is Singletons are Pathological Liars by Miško Hevery. Essentially, they encourage "hidden" behaviour that is very hard to learn and test.

There are projects where you can't practically avoid using globals. All kinds of service locators or dependency-injection frameworks still rely on global (not always static variable, but always global of some sort) storage of objects.

However, singletons are a sign of a problem:

• First, singleton as a canonical pattern doesn't go well with interfaces and abstraction. It can be fixed though - accessing it through factory.
• Worse, singletons are inflexible - they don't have any means of identifying object beyond its type. ( Well, in C++ they do through templates, but it's a different story). In that sense they are actually worse than static variables. In the long run it pays off using a framework where many instances of the same type can be accessed.
• And most importantly, lots of singletons means lots of distant relationships between objects. Which means your system is probably more complex than it needs to be and will be much harder to develop, test and manage. Simply switching to locators or DI won't help there, it's a matter of underlying design principles.

A singleton is effectively global state. If you're going to create lots of singletons you're going to create lots of global state, only in won't necessarily look like global state.

This makes it hard to do things like build unit tests, provide mock classes and reuse code because its really easy to couple the current state to a function. i.e. function foo is only valid when class X is in state Z, otherwise it doesn't work.

It's also problematic to build a thread safe singleton correctly.

Singletons can be good for coordinating access to a resource, particularly one that doesn't have much state and is expensive to construct.

So why do you think you need lots of singletons? you may get better responses if you ask about your problem domain and what issue you are hitting.

In programming there are no silver bullets. Making every class a singleton will not magically make your code "better". Singletons are a tool for that solve a specific problem I studying more about singletons.

To use singleton pattern in your project should be a well thought out and careful design decision, because its a one way track with very little scope for backtracking. I have practically used it in one of my project for a commercial product in a multithreading environment and faced multitude of problems. But this doesn't mean it's an untouchable pattern. The point is anything which can be achieved with singleton can be achieved without it, with less hassles and complexity. For more on this you can track this question I asked some months back. It has interesting links and insight into the singleton pattern