Are there any viable alternatives to the GOF Singleton Pattern?

Question

Let's face it. The Singleton Pattern is highly controversial topic with hordes programmers on both sides of the fence. There are those who feel like the Singleton is nothing more then a glorified global variable, and others who swear by pattern and use it incessantly. I don't want the Singleton Controversy to lie at the heart of my question, however. Everyone can have a tug-of-war and battle it out and see who wins for all I care. What I'm trying to say is, I don't believe there is a single correct answer and I'm not intentionally trying inflame partisan bickering. I am simply interested in singleton-alternatives when I ask the question:

Are their any specific alternatives to the GOF Singleton Pattern?

For example, many times when I have used the singleton pattern in the past, I am simply interested in preserving the state/values of one or several variables. The state/values of variables, however, can be preserved between each instantiation of the class using static variables instead of using the singleton pattern.

What other idea's do you have?

EDIT: I don't really want this to be another post about "how to use the singleton correctly." Again, I'm looking for ways to avoid it. For fun, ok? I guess I'm asking a purely academic question in your best movie trailer voice, "In a parallel universe where there is no singleton, what could we do?"

Answer 1

To understand the proper way to workaround Singletons, you need to understand what is wrong with Singletons (and global state in general):

Singletons hide dependencies.

Why is that important?

Because If you hide the dependencies you tend to lose track of the amount of coupling.

You might argue that

void purchaseLaptop(String creditCardNumber, int price){   CreditCardProcessor.getInstance().debit(creditCardNumber, amount);   Cart.getInstance().addLaptop(); } 

is simpler than

void purchaseLaptop(CreditCardProcessor creditCardProcessor, Cart cart,                      String creditCardNumber, int price){   creditCardProcessor.debit(creditCardNumber, amount);   cart.addLaptop(); } 

but at least the second API makes it clear exactly what the method's collaborators are.

So the way to workaround Singletons is not to use static variables or service-locators, but to change the Singleton-classes into instances, which are instantiated in the scope where they make sense and injected into the components and methods that need them. You might use a IoC-framework to handle this, or you might do it manually, but the important thing is to get rid of your global state and make the dependencies and collaborations explicit.

Answer 2

Alex Miller in "Patterns I Hate" quotes the following:

"When a singleton seems like the answer, I find it is often wiser to:

1. Create an interface and a default implementation of your singleton
2. Construct a single instance of your default implementation at the “top” of your system. This might be in a Spring config, or in code, or defined in a variety of ways depending on your system.
3. Pass the single instance into each component that needs it (dependency injection)