Dave Handley wrote:
Jason Hise wrote:
Pavel and I have been discussing a sibling class to the singleton, namely a multiton. Such a class would manage a unique object instance for each key provided to GetInst. It should be able to use many of the same policies that the singleton uses.
Pavel thinks that it could be useful to allow GetInst to take any number of parameters. Would this actually be useful, and if so, how could such a design be achieved?
<> I think that "multitons" are very useful - but I'm not sure that a Singleton class should necessarily be bloated out to support them.
I agree entirely... which is why I plan to make multiton a sibling class instead of making the singleton support it with additional policies. It will live in the same namespace and possibly be able to utilize some of the same policies that the singleton does (for instance any allocator that doesn't restrict creation to one instance)
<> The way I have normally implemented this type of structure is to have a class that is itself a singleton, but is responsible for generating and returning one of a fixed (or variable) number of classes. If you implement the interface through a static function that delegates through the singleton GetInst function, you get a very simple interface which doesn't detract from a nice simple singleton interface - eg:
class Multiton : public Singleton<Multiton> { public: class Child; static Child *GetInst( int number ) { return GetInst()->GetChild( number ); } private: Child *GetChild( int number ) { // TODO: check for and return the correct instance of Child } };
Is this pretty much what you were thinking?
Almost. The key passed in to GetInst would be templated, and Child would be the multiton itself. However, upon further meditation I wonder if having Child a separate type would be preferable. I guess the question at hand is how important it is to enforce that there can only be instances that correspond to a key. With your model, anyone could easily instantiate a Child. -Jason