En ingeniería de software , el patrón multiton es un patrón de diseño que generaliza el patrón singleton . Mientras que el patrón singleton permite crear solo una instancia de una clase, el patrón multiton permite la creación controlada de múltiples instancias, que gestiona mediante el uso de un mapa .
En lugar de tener una única instancia por aplicación (por ejemplo, el java.lang.Runtimeobjeto en el lenguaje de programación Java ), el patrón multitono garantiza una única instancia por clave .
El patrón multiton no aparece explícitamente como patrón en el prestigioso libro de texto de programación orientada a objetos Design Patterns . [1] Sin embargo, el libro describe el uso de un registro de singletons para permitir la subclasificación de singletons, [2] que es esencialmente el patrón multiton. [ cita requerida ]
Aunque parezca que el multiton es una tabla hash con acceso sincronizado, existen dos distinciones importantes. En primer lugar, el multiton no permite que los clientes agreguen asignaciones. En segundo lugar, el multiton nunca devuelve una referencia nula o vacía; en cambio, crea y almacena una instancia del multiton en la primera solicitud con la clave asociada. Las solicitudes posteriores con la misma clave devuelven la instancia original. Una tabla hash es simplemente un detalle de implementación y no el único enfoque posible. El patrón simplifica la recuperación de objetos compartidos en una aplicación.
Dado que el grupo de objetos se crea solo una vez, al ser un miembro asociado a la clase (en lugar de la instancia), el multiton conserva su comportamiento plano en lugar de evolucionar hacia una estructura de árbol .
El multiton es único en el sentido de que proporciona acceso centralizado a un único directorio (es decir, todas las claves están en el mismo espacio de nombres, per se ) de multitons, donde cada instancia de multiton en el grupo puede existir con su propio estado . De esta manera, el patrón aboga por el almacenamiento indexado de objetos esenciales para el sistema (como el que proporcionaría un sistema LDAP , por ejemplo). Sin embargo, un multiton está limitado a un amplio uso por parte de un único sistema en lugar de una miríada de sistemas distribuidos.
Este patrón, al igual que el patrón Singleton , hace que las pruebas unitarias sean mucho más difíciles, [3] ya que introduce un estado global en una aplicación.
Con idiomas que recolectan basura, puede convertirse en una fuente de pérdidas de memoria, ya que introduce fuertes referencias globales a los objetos.
En Java, el patrón multiton se puede implementar utilizando un tipo enumerado , con los valores del tipo correspondientes a las instancias. En el caso de un tipo enumerado con un solo valor, esto da como resultado el patrón singleton.
En C#, también podemos utilizar enumeraciones, como muestra el siguiente ejemplo:
usando Sistema ; utilizando System.Collections.Generic ; enumeración pública MultitonType { Cero , Uno , Dos}Clase pública Multiton { Diccionario privado estático de solo lectura < MultitonType , Multiton > instancias = nuevo Diccionario < MultitonType , Multiton > (); tipo MultitonType privado ; Multiton privado ( tipo MultitonType ) { este . tipo = tipo ; } público estático Multiton GetInstance ( tipo MultitonType ) { // Inicio perezoso (no seguro para subprocesos como está escrito) // Se recomienda utilizar el bloqueo de doble verificación si se necesita seguridad para el hilo si ( ! instancias . TryGetValue ( tipo , salida var instancia )) { instancia = nuevo Multiton ( tipo ); instancias . Agregar ( tipo , instancia ); } devolver instancia ; } cadena de anulación pública ToString () { devuelve "Mi tipo es " + este . tipo ; } // Ejemplo de uso público estático void Main () { var m0 = Multiton . GetInstance ( MultitonType . Zero ); var m1 = Multiton . GetInstance ( MultitonType . One ); var m2 = Multiton . GetInstance ( MultitonType . Two ); Consola .WriteLine ( m0 ) ; Consola .WriteLine ( m1 ) ; Consola .WriteLine ( m2 ) ; }}