Seguimos con el segundo patrón de diseño de BBDDOO.
Persistent Singleton
Otros de los problemas más frecuentes que se resuelve con un patrón es el siguiente: el acceso a una base de datos orientada a objetos típicamente comienza por encontrar un punto de entrada usando un nombre conocido de algún tipo. Los programadores pueden usar directamente la API de la base de datos para encontrar este punto de entrada cada vez que lo necesite, pero esto “ensuciará” al código con estos nombres conocidos, ya que introduce dependencias implícitas a través del código, y dependiendo del motor de la base de datos en cuestión, podría ser un poco menos eficiente que buscarlo una vez y luego el mantener un puntero a este objeto para su posterior uso.
Encapsulando este código dentro de un Persistent Singleton, se asegura de que sólo hay
una instancia de este objeto de punto de entrada, mantiene este nombre conocido en un solo lugar, y proporciona un cómodo acceso global usando una variante de este modelo bien establecido.
El propósito del Singleton entonces, es controlar la creación de objetos, limitando el número de instancias a uno pero permitiendo la flexibilidad de crear más objetos si la situación cambia. Dado a que hay una sola instancia de Singleton, los campos de instancia de un Singleton ocurrirán una sola vez por clase, al igual que los campos estáticos.
Los Singletons, a menudo controlan el acceso a recursos tal como conexiones a bases de datos. Por ejemplo, si se tiene licencia para una sola conexión a una base de datos, el Singleton asegura que solo una conexión se ha establecido o que solo un hilo por vez puede acceder a la conexión. Si se agregan conexiones, el Singleton puede ser fácilmente ajustado para permitir más conexiones.
- Aplicabilidad
Es utilizable el patrón Persistent Singleton cuando:
- Hay puntos de entrada a la base de datos que deben ser encontrados usando un nombre conocido.
- Cuando la única instancia debe ser extensible por la sub-clasificación, y que los clientes deben ser capaces de utilizar una instancia extendida sin modificar su código.
- Estructura
- Otros ejemplos y aplicaciones del Persistent Singleton
Otro ejemplo de uso del patrón es cuando el Singleton tiene estado, en este caso, su función es servir como un repositorio único de estado. Si se esta implementando un contador que necesita devolver números únicos y en secuencia (por ejemplo, la máquina que da los números en casas comestibles), el contador necesita ser globalmente único. El Singleton puede contener el número y sincronizar el acceso; si luego se quiere mantener el contador en base de datos para la persistencia, se puede cambiar la implementación privada del Singleton sin cambiar la interfaz.
Por otro lado, los Singletons pueden ser sin estado, proveyendo funciones de utilidad que no necesitan más información que sus parámetros. En este caso, no hay necesidad de crear múltiples instancias del objeto ya que no tienen razón de existencia, en este caso un Sinlgeton es apropiado también.
Sin embargo, en ciertas situaciones, dos o más Singletons, pueden misteriosamente materializar, alterando la garantía que el Singleton esta destinado a proporcionar. Por ejemplo, si un marco de Singleton se entiende como una interfaz de usuario global para su aplicación y se crean dos, la aplicación tendrá dos marcos en la pantalla, bastante confuso para el usuario. Además, si se crean dos contadores, donde se suponía uno solo, entonces los clientes que solicitan un número no tendrá la secuencia deseada 1, 2, 3…, sino más bien una secuencia de múltiples tales como 1, 1, 2, 2, 3, 3, 3 ….Además, si varias instancias de -conexión de bases de datos Singleton- se crean, es posible que empiece a recibir Excepciones de bases de datos, como “demasiadas conexiones de base de datos “.
Colaboraciones
Los clientes acceden al Singleton solo a través del método getInstance().
El patrón Singleton tiene todas las ventajas de su relación transitoria:
- Controlar el acceso a la única instancia. Gracias a que la clase del Persistent Singleton encapsula la única instancia, puede tener estricto control sobre como y cuando los clientes acceden a la misma.
- Espacio de nombres reducido. El patrón Persistent Singleton es una mejora sobre las variables globales. Evita la contaminación del espacio de nombres con las variables globales que almacenan las instancias.
- Permite el perfeccionamiento de las operaciones y representación. La clase Persistent Singleton puede ser sub-clasificada, y es fácil de configurar una aplicación con una instancia de esta clase extendida. Se puede configurar la aplicación con una
instancia de la clase que necesita en tiempo de ejecución. - Permite un número variable de casos. El patrón hace que sea fácil de cambiar y permitir más de una instancia de la clase Persistent Singleton.
Además, puede utilizar el mismo método para controlar el número de instancias
que utiliza la aplicación. Sólo la operación que permite el acceso a la instancia de Persistent Singleton tiene que cambiar. - Más flexible que las operaciones de clase. Otra manera de empaquetar la funcionalidad del Persistent Singleton es usar las funciones de miembros estáticos, pero esto hace difícil de cambiar un diseño que permita mas de una instancia de la clase.
Sin embargo, con un Peristent Singleton existen otras consideraciones:
- Un Singleton transitorio utiliza un puntero para referenciar a la instancia única. Usando este patrón, es necesario asegurarse que el miembro de datos de la instancia es de un tipo tal que pueda ser reutilizado desde una transacción a otra. Con algunos OODBMs esto puede ser técnicamente posible de acceder al Persistent Singleton fuera de la transacción; el programador necesita decidir si tal acceso no transaccional debe ser permitido.
- Alcance del Persistent Singleton. En los sistemas con múltiples bases de datos, ya que estos singletons a menudo se utilizan para encapsular puntos de entradas de base de datos, puede ser el problema cuantos Singletons realmente hay, y cual base de datos realmente contiene la instancia del Singleton relevante del contexto actual. Una solución es proporcionar un método de inicialización estática que
toma algún tipo de identificador de base de datos como argumento, y determina cual base de datos es accedida para encontrar o crear la instancia persistente. - Acceso a bases de datos. En una llamada al método getInstance (), la última transacción consistente de la instancia de Persistent Singleton debe ser retornada, y esto puede requerir acceso a la base, pero no se quiere cargar al caller con la tarea de recordar recordar el identificador de base de datos correcta y pasarlo en todo momento. Una solución es proporcionar un método de inicialización estática que se llama una vez al principio del programa y toma algún tipo de identificación de la base de datos como un argumento. El Singletonn puede almacenar en caché la referencia a la base de datos para su uso posterior cuando getInstance() es llamada.
- La construcción de objetos persistente requiere una transacción de escritura. Una típica implementación de Singleton comprueba si _instance es null, y por lo tanto si la única instancia se crea antes de ser devuelta. La construcción de un Persistent Singleton requeriría una transacción de escritura, lo que significa el acceso al
Singleton en una transacción de sólo lectura es técnicamente inseguro. Una
solución, es proporcionar un método de inicialización estática que tiene algún tipo de identificación de la base de datos como argumento. Esto se llama una vez al inicio del programa y se intenta encontrar el Persistent Singleton en la base de datos pasada. Si no se encuentra, el singleton es creado y una transacción de escritura se inicia como requiere. A partir de entonces, todas las llamadas a getInstance () están garantizadas para encontrar la única instancia y con seguridad se puede llamar en una transacción de sólo lectura.
- Ejemplo de Código
