“Singleton” factories, ok or bad?

Question

I\'ve a lot of (abstract) factories and they\'re usually implemented as singletons.

Usually for the convenience of not having to pass them through layers who really hav

Answer 1

No, because what you're doing here is creating global state. There are all sorts of problems with global state - chief among them that one function then depends in rather invisible way on the behavior of other functions. If a function calls another function that forgets to store and restore the factory before it finishes, then you have a problem because you can't even get the old value back unless you stored it somewhere. And you have to add code to do that (judging by your code, I'd guess you're in a language with finally, which leaves even more room for mistakes). What's more, if you end up with code that needs to switch between two factories quickly for two subobjects, you have to write a method call at each point - you can't store the state in each subobject (well, you can, but then you defeat the purpose of global state [which admittedly isn't much]).

It probably makes the most sense to store the factory type as a member, and pass it to the constructor of new objects that need it (or create a new one as needed, etc.). It also gives you better control - you can guarantee that all objects constructed by object A went through the same factory, or you can offer methods to swap factories out.