Patrón de diseño de creación: 1. Patrón de singleton

¿Qué es un patrón de diseño de creación?

(26 de diciembre de 2020)

Los patrones de diseño de creación tratan con la creación o clonación de nuevos objetos de una clase. La clonación ocurre cuando ya existe un tipo de objeto similar y en lugar de crear una instancia de un objeto nuevo, clonamos el existente.

Las diferentes formas de crear objetos influirán en gran medida en cómo se resuelve un problema. Por lo tanto, los diferentes lenguajes influyen en los patrones que se pueden usar.

Patrón Singleton

El patrón Singleton se usa cuando solo necesitamos una instancia única de una clase. Por ejemplo, hacer una conexión a la base de datos en una aplicación, imprimir la cola de la impresora, usar registradores ya que requieren muchos recursos. En todos esos casos, si hay varias instancias, se creará confusión e incoherencia.

Este patrón se usa cuando la instancia se comparte y se puede acceder a ella globalmente en toda la aplicación. Asegurarse de que el acceso a los recursos compartidos sea seguro para subprocesos es un muy buen ejemplo de donde este tipo de patrón puede ser vital. La intención de un patrón Singleton es proporcionar acceso global a una clase que está restringida a una instancia.

Veamos cómo se crea el objeto

public class DummyClass{ DummyClass(){}
}DummyClass dc = new DummyClass(); //every time when this line is called a new object of DummyClass is created

Ahora, siempre que se necesita un objeto de DummyClass, se llama a su constructor y se crea un objeto. Esto se llama inicialización ansiosa.

Pero, en el patrón singleton, solo requerimos una única instancia de una clase. Digamos, si una conexión de base de datos ya está configurada, no necesitamos crear una nueva conexión de base de datos y deberíamos usar la conexión ya existente. Veamos cómo lograrlo.

Aquí, hemos limitado el alcance del constructor a la propia clase. Entonces, para crear el objeto de esta clase, se debe llamar al método estático getDBConnection () de la clase. Luego verificará si el objeto dbConnection es nulo, luego creará un nuevo objeto de conexión y devolverá, de lo contrario, devolverá el objeto de conexión existente.

Este ejemplo demuestra el concepto de inicialización diferida . Eso significa que no estamos creando el objeto de la clase a menos que sea realmente necesario. Por lo tanto, este programa es más eficiente en términos de recursos.

Existen compensaciones en el principio de diseño de Singleton. Si hay varios subprocesos informáticos en ejecución, podría haber problemas causados ​​por los subprocesos que intentan acceder al único objeto compartido.

Problemas en la implementación anterior

Ahora, es posible que dos los subprocesos al mismo tiempo están llamando al método getDBConnection y el objeto aún no se ha creado. Para ambos hilos, el objeto dbConnection será nulo y ambos intentarán crear una nueva instancia y usarla en su lugar. Por lo tanto, es muy importante asegurarse de que un solo hilo pueda acceder a getDBConnection a la vez para que no se creen varias instancias.

Para lograr un hilo -safe la clase singleton es sincronizar el método de acceso global, de modo que solo un hilo pueda ejecutar este método a la vez.

Solo un hilo puede acceder a este bloque de código sincronizado a la vez

Puede que esté pensando que el problema ya está resuelto. ¡Pero, lamentablemente, no! Para hacer cumplir la propiedad singleton, bloqueamos el método estático getDBConnection pero comprometemos su rendimiento al mismo tiempo. Cuando un objeto ya está creado, también, varios subprocesos deben esperar para obtener la instancia existente de ese objeto. ¿Podemos hacer algo mejor? Veamos.

Como es evidente, el bloqueo solo es necesario cuando la instancia es nula para que diferentes subprocesos no creen múltiples instancias. Entonces, podemos poner una condición sincronizada dentro de la condición if donde estamos verificando si la instancia es nula o no, y agregar una doble verificación para eliminar los escenarios de múltiples instancias.

En uso real, el patrón singleton se puede implementar de diferentes formas. Simplemente define el propósito básico que cumple este patrón, pero la implementación del código puede diferir.

Eso es todo por mi parte. Espero que ahora esté claro dónde, cuándo y cómo usar el patrón de diseño singleton. Puede consultar el libro, el catálogo de patrones de diseño de Gang of Four para obtener más información.

Si tiene alguna duda, hágamelo saber en los comentarios a continuación. Si te gusta este blog, compártelo con tus amigos. ¡Feliz ingeniería de software!

Parte 2: