I'm pretty well sold on the "singletons are evil" line of thought. Nevertheless, there are limited occurrences when you want to limit the creation of an object. Roy Osherove advises,

> If you're planning to use a singleton in your design, separate the logic of the singleton class and the logic that makes it a singleton (the part that initializes a static variables, for example) into two separate classes. That way, you can keep the single responsibility principle (SRP) and also have a way to override singleton logic. (261-262)

This pattern still perpetuates the global state. However, it does result in a testable design, so it seems to me to be a good pattern for mitigating the damage of a singleton.

However, Osherove does not give a name to this pattern; but naming a pattern, according to the Gang of Four, is important:

> Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. (3)

Is there a standard name for this pattern? It seems different enough from a standard singleton to deserve a separate name. *Decoupled Singleton*, perhaps?