Name for Osherove's modified singleton pattern?

Question

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. (The Art of Unit Testing 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?

Answer 1

It's a Singleton combined with a Factory Method, such that the calling code has no idea that it is dealing with a singleton, or even the class it's dealing with. Even the class itself doesn't know it's a Singleton. The factory can be mocked out, making testing possible but, within the context of the application, it is always the same object returned.

I have seen a few sites call it a Singleton Factory, to distinguish the two.

It is common now to make this kind of decision (sometimes dangerously, as if you're no longer dealing with a true Singleton, so it doesn't matter) in the process of registering objects with an IoC container, making the name largely irrelevant.

Answer 2

It is the singleton pattern. It's description as a design would be no different than the original singleton. It is just an implementation variation.

Answer 3

The "singleton pattern" embodies a a couple of different concepts: (1) some sort of object is implicitly shared; (2) the object may be lazily created without changing the observable system state. While these concepts often go together, some applications will use one without the other.

For example, a system may use a thread-static variable to hold a reference to the current database. When each thread that will need the data base is initiated, it grabs a copy of a global "current database" setting and uses that to get a reference to the current database which it will then use until it has run to completion. Since many methods will all use the current database, explicitly passing around a reference to it may be cumbersome, and saying "all methods operate on the thread's current database, as defined by _" may be make the code cleaner than having to explicitly pass a reference to the database with every function call. Note that in this scenario, there is an object which is shared implicitly, but its creation alters the system state.

Alternatively, a program may have a variety of static instances of objects implementing IGetGlobalWidget with a virtual GetWidget method. These objects, being static, are created at program startup rather than being lazily generated, and each of these objects when used will lazily (if necessary) create some sort of Widget derivative and return a reference to it. Rather than passing around Widget references, code passes around references to implementations of IGetGlobalWidget. Any particular IGetGlobalWidget implementation will always return the same Widget-derivative instance, and the lazy creation will not affect visible program state, but code could control which methods will share widgets, by which methods share IGetGlobalWidget objects.