Talk:Multiton pattern

message: Pending further discussion here, I removed a strange assertion that multiton is viewed as an antipattern by "advocates of dependency injection". I for one often advocate dependency injection, while also often using multiton (albeit not with statics) on the same project e.g. when deserializing some richly interelated data that had to pass through some intermediate format that had little direct ability to express relationships. These days, relational data passing through an XML format is a common example, since XML expresses hierarchy only while relational supports more general network graphs that may need to be reassembled by keying off instance IDs. If someone wants to put it back, please explain here first so we can discuss.
Bmord (talk) 20:07, 7 January 2010 (UTC)
thread_title: Multiton an Antipattern? Please explain here

message: For the second time I have had to remove incorrect commentary on this subject.  Please add discussion here if you have questions.
Dubwai 15:52, 19 June 2006 (UTC)
thread_title:  Please discuss changes here first 

message: How does the Multiton differ from a Singleton Collection? Basically, there's one collection, instead of one object. Perhaps this is why the GoF mentioned it only as a footnote to the Singleton?
Also, I see the lock in the C# example, but I thought that static variables were guaranteed thread-safe. Besides wasting clock cycles, what does the lock buy you?  
Answered my own question on the second part via this thread: http://support.microsoft.com/kb/816161. It seems the lock isn't used to ensure thread-safety, so much as it is used to prevent another thread from seeing a static object in an invalid state. It's unclear if seeing this invalid state would result in an exception or not. For anyone else out there confused by the common mantra of "Any shared member variables or functions are thread-safe..." from MSDN articles, this means only that MS has made their shared members thread-safe, not that shared members or methods are inherently thread-safe. Wish this had been stated as clearly in the article here.
—Preceding unsigned comment added by KnockNrod (talk • contribs) 16:07, 21 September 2010 (UTC)
thread_title:  Multiton = Singleton Collection? 

message: Shouldn't all these examples be replaced by just one?  Then put the rest in wikibooks.  — Preceding unsigned comment added by 70.173.192.81 (talk) 19:05, 15 September 2013 (UTC)
thread_title:  Remove most of these languages 

message: Hello, I don't want to change it right away because i'm not sure if i'm right and the php version won't work in the way i see it. But i have the gang of four book right before me and i'm a bit curious if there's a reason that not all constructors are protected. I mean: singletons with a public constructor are kind of useless, because you can't be sure that there's really only 1 instance (or 1 instance for a key in the case of a multiton). The most accurate example seems to be the c++ version because it also declares the copyconstructor as private.
So is there anything against making the map and constructors protected?
- public constructors + public copyconstructors / clone methods can be used to bypass the registry
- protected - you are able to define subclasses of the multiton
The php example won't work with protected methods out of the box because of the reflectionclass. Anyone with some good ideas? --DarkXTC90 (talk) 17:28, 6 February 2014 (UTC)
thread_title:  Contstructor and clone