Multiton pattern
From Wikipedia, the free encyclopedia
In software engineering, the multiton pattern is a design pattern similar to the singleton, which allows only one instance of a class to be created. The multiton pattern expands on the singleton concept to manage a map of named instances as key-value pairs.
Rather than have a single instance per application (e.g. the java.lang.Runtime object in the Java programming language) the multiton pattern instead ensures a single instance per key.
Most people and textbooks consider this a singleton pattern. For example, multiton does not appear in Design Patterns, the highly-regarded object-oriented programming text book.
An example thread-safe Java implementation follows:
Contents |
[edit] Example
[edit] Java
public class FooMultiton
{
private static final Map<Object, FooMultiton> instances = new HashMap<Object, FooMultiton>();
private FooMultiton() // also acceptable: protected, {default}
{
/* no explicit implementation */
}
public static FooMultiton getInstance(Object key)
{
synchronized (instances) {
// Our "per key" singleton
FooMultiton instance;
if ((instance = instances.get(key)) == null) {
// Lazily create instance
instance = new FooMultiton();
// Add it to map
instances.put(key, instance);
}
return instance;
}
}
public Foo getFoo()
{
/* implementation not pertinent to pattern */
}
public void setFoo(Foo foo)
{
/* implementation not pertinent to pattern */
}
}
[edit] Python
class Multiton(object): def __init__(self): self.instances = {} def __call__(self, key, instance): self.instances[key] = instance def get_instance(self, key): return self.instances[key] class A: def __init__(self, *args, **kw): pass m = Multiton() a0 = m('a0', A()) a1 = m('a1', A()) print m.get_instance('a0') print m.get_instance('a1')
[edit] Clarification of example code
While it may appear that the multiton is no more than a simple hash table with synchronized access there are two important distinctions. First, the multiton does not allow clients to add mappings. Secondly, the multiton never returns a null or empty reference; instead, it creates and stores a multiton instance on the first request with the associated key. Subsequent requests with the same key return the original instance. A hash table is merely an implementation detail and not the only possible approach. The pattern simplifies retrieval of shared objects in an application.
Since the object pool is created only once, being a member associated with the class (instead of the instance), the multiton retains its flat behavior rather than evolving into a tree structure.
The multiton is unique in that it provides centralized access to a single directory (i.e. all keys are in the same namespace, per se) of multitons, where each multiton instance in the pool may exist having its own state. In this manner, the pattern advocates indexed storage of essential objects for the system (such as would be provided by an LDAP system, for example). However, a multiton is limited to wide use by a single system rather than a myriad of distributed systems.
[edit] Drawbacks
It should be noted that this pattern, like the Singleton pattern, makes unit testing far more difficult[1], as it introduces global state into an application.
Advocates of dependency injection would regard this as an anti pattern, mainly due to its use of private and static methods.
