Martin Aspeli wrote:
For the record, I normally use the singleton analogy to explain unnamed global utilities. Perhaps that's bad, though I find it works pretty well. It'd probably be more accurate to use the terms you did, an "extension of the singleton principle", but as you say, it just adds more complexity.
To me, the Singleton pattern says, "each time you ask for this, you get the same object". That's a little bit different from "this class can only be instantiated once". I think the important part of the design pattern is the shared instance (e.g. to conserve resources or to implement some kind of shared counting/tracking), not the restrictions on instantiation.
I'm certainly -1 on using the term in the ZCA. I think changing our nomenclature would be terrible for the same reasons I think changing (as opposed to extending/improving) our API would be terrible. Utilities are in one way a more specific concept (due to the lookup semantics) and in another way a more generic concept (since named utilities can be used to implement a registry of homogenous objects).
To me the fact that an object "is" a singleton or a factory is orthogonal to the registry stuff. Why can't utilities be factories too that simply return themselves when being called? Then being a singleton or not would be in the responsibility of the registered object (class, factory, singleton) and the ZCA would not need to know. What am I missing (except bbb)?