The '''Instance manager pattern''' (I've used it before, so I can call it a "pattern") is proposed as a replacement for many (not necessarily all) uses of SingletonPattern.  In SingletonPattern, a class is burdened with the additional duty (beyond the fundamental purpose of the class) of managing it's instance(s); the management policy might change from application to application.  Furthermore, SingletonPattern more or less fixes the domain of uniqueness to the process; whereas it might be highly useful for different modules within a program to have their own copies of the object in question.  Or, multiple processes might want to share an instance of some service.  Finally, inheriting from a singleton has lots of problems of its own.

Thus, the InstanceManagerPattern.

An '''instance manager''' is a class/object which serves to manage instance(s) of some other type of object, and provide a point of access to the instances being managed.  Such a class should generally have the following methods:

* Ability to set the number of instances being managed

* Ability to place an instance of whatever is being managed under management.  (Note that the ability to ''construct'' instances of the singleton is not constrained, just the ability to manage them).

* Ability to look up one or more instances (via a key) of the managed object(s).  If only one managed object, then a key is not necessary.

* Optionally, the ability to remove an object from management (which does not cause the object's destruction).

In multi-threaded languages, such a creature should be threadsafe, obviously.  One nice thing about an instance manager is that since it is a) lightweight (not expensive to construct), and b) it's initial state is not runtime-dependent, it doesn't suffer from the "bootstrapping" problem that plagues (and complicates) many singleton impementations.  Just have a static instance of one of these for every singleton you want to create.   

Sounds like you're describing the RegistryPattern http://www.martinfowler.com/eaaCatalog/registry.html from PatternsOfEnterpriseApplicationArchitecture.


''Good idea!  I will make myself a global Instance Manager and make sure that I can get to it everywhere with a nice static getInstance method.''

Exactly. Ever had something that looks like a singleton but is not. I'm looking at that case. Oh, and an InstanceManager can simply be declared as public static variablename because its constructor is a semantic NoOp.

----

The "look up one or more instances" part would seem to indicate a variant of ReverseFlyweightPattern, which I created as a way to generalize singletons--and which in retrospect, should probably have been called the ''n''-ton pattern (''n''-pleton pattern?). But I now realize that both RFP and Singleton pattern suffer from the inability to 'swap out' singletons/instances easily (for debugging purposes, or subbing in more descriptive loggers); hence, what might really be needed to "fix" Singleton is something to provide ExplicitManagementOfImplicitState.

On the other hand, your version provides the appealing prospect of re-using the same InstanceManager class for multiple Singleton classes, thus removing the giant copy-and-paste smell that makes Singleton so typically hard to stomach.