I have read different opinions about the singleton pattern. Some maintain that it should be avoided at all costs and others that it can be be useful in certain situations.
One situation in which I use singletons is when I need a factory (let's say an object f of type F) to create objects of a certain class A. The factory is created once using some configuration parameters and then is used each time an object of type A is instantiated. So every part of the code that wants to instantiate A fetches the singleton f and create the new instance, e.g.
F& f = F::instance(); boost::shared_ptr<A> a = f.createA();
So the general my scenario is that
- I need only one instance of a class either for optimization reasons (I do not need multiple factory objects) or for sharing common state (e.g. the factory knows how many instances of A it can still create)
- I need a way to have access to this instance f of F in different places of the code.
I am not interested in the discussion whether this pattern is good or bad, but assuming I want to avoid using a singleton, what other pattern can I use?
The ideas I had were (1) to get the factory object from a registry or (2) to create the factory at some point during program start up and then pass the factory around as a parameter.
In solution (1), the registry itself is a singleton, so I have just shifted the problem of not using a singleton from the factory to the registry.
In case (2) I need some initial source (object) from which the factory object comes so I am afraid that I would again fall back to another singleton (the object that provides my factory instance). By following back this chain of singletons I can maybe reduce the problem to one singleton (the whole application) by which all other singletons are directly or indirectly managed.
Would this last option (using one initial singleton that creates all other unique objects and injects all other singletons at the right places) be an acceptable solution? Is this the solution that is implicitly suggested when one advises not to use singletons, or what are other solutions, e.g. in the example illustrated above?
Since I think the point of my question has been misunderstood by some, here is some more information. As explained e.g. here, the word singleton can indicate (a) a class with a single instance object and (b) a design pattern used to create and access such an object.
To make things clearer let us use the term unique object for (a) and singleton pattern for (b). So, I know what the singleton pattern and dependency injection are (BTW, lately I've been using DI heavily to remove instances of the singleton pattern from some code I am working on).
My point is that unless the whole object graph is instantiated from a single object living on the stack of the main method, there will always be the need to access some unique objects through the singleton pattern.
My question is whether having the complete object graph creation and wiring depend on the main method (e.g. through some powerful DI framework that does not use the pattern itself) is the only singleton-pattern free solution.