Está en la página 1de 13

UNIVERSIDAD LAICA ELOY ALFARO DE MANABÍ

FACULTAD DE CIENCIAS INFORMÁTICAS



ASIGNATURA:
HERRAMIENTAS CASE
NOMBRE:
BELLO FLORES RAMÓN DAVID

CURSO:
7° NIVEL “B”

PROFESOR:
ING. FREDDY ALARCON

MANTA-MANABÍ-ECUADOR

Tabla de Contenido
Tema: ........................................................................................................................................................... 3
Glosario: ..................................................................................................................................................... 3
Acoplamiento: ....................................................................................................................................... 3
Antipatrón: . ........................................................................................................................................... 3
Singleton:. .............................................................................................................................................. 3
Introducción .............................................................................................................................................. 3
Contenido ................................................................................................................................................... 4
Estructura .................................................................................................................................................. 5
Ejemplo: ...................................................................................................................................................... 6
Conclusión. .............................................................................................................................................. 12
Recomendaciones ................................................................................................................................. 12
Bibliografía............................................................................................................................................... 13




















Tema:

PATRÓN DE DISEÑO SINGLETON

Glosario:

Acoplamiento: junto con la modularidad, la cohesión y otros factores, permiten mejorar la
programación y el diseño de sistemas informáticos y aplicaciones, y son muy importantes en el
incremento de la reutilización de los códigos.ios

Antipatrón: de diseño es un patrón de diseño que invariablemente conduce a una mala
solución para un problema.

Singleton: es un patrón que garantiza que una clase sólo tenga una instancia y proporciona un
punto de acceso global a ésta instancia.

Introducción

Cuando se habla de un patrón de diseño se refiere a una solución de un problema concreto en
el desarrollo de software. Pero no cualquier solución, sólo aquellas que se ha demostrado
que son eficientes en diferentes escenarios y reutilizables en gran cantidad de contextos de
aplicaciones.

Los patrones de diseños no fueron inventados fueron descubierto.

En este caso se tártara el patrón de diseño Singleton el cual garantiza que una clase sólo
tenga una instancia y proporciona un punto de acceso global a ésta instancia.


Contenido

Patrón de diseño: Singleton
El patrón Singleton garantiza que una clase sólo tenga una instancia y proporciona un punto de
acceso global a ésta instancia.
El patrón Singleton asegura que exista una única instancia de una clase. A primera vista, uno
puede pensar que pueden utilizarse clases con miembros estáticos para el mismo fin.
Sin embargo, los resultados no son los mismos, ya que en este caso la responsabilidad de
tener una única instancia recae en el cliente de la clase. El patrón Singleton hace que la clase
sea responsable de su única instancia, quitando así este problema a los clientes.
Adicionalmente, si todos los métodos de esta clase son estáticos, éstos no pueden ser
extendidos, desaprovechando así las capacidades polimórficas que nos proveen los entornos
orientados a objetos.

El funcionamiento de este patrón es muy sencillo y podría reducirse a los siguientes conceptos:

1. Ocultar el constructor de la clase Singleton, para que los clientes no puedan crear
instancias.

2. Declarar en la clase Singleton una variable miembro privada que contenga la referencia
a la instancia única que queremos gestionar.

3. Proveer en la clase Singleton una función o propiedad que brinde acceso a la única
instancia gestionada por el Singleton. Los clientes acceden a la instancia a través de
esta función o propiedad.

Estas reglas se cumplen en todas las implementaciones del Singleton, independientemente de
los recaudos que deban tomarse para soportar la correcta ejecución en entornos multihilo.
( http://msdn.microsoft.com, s.f.)








Estructura












Ejemplo:
Teniendo en cuenta estas características vamos a desarrollar una clase singleton:



En esta pequeña porción de código hemos conseguido realizar una única instancia en el momento en el
que se llama por primera vez. Además hemos creado un constructor con acceso privado para que nadie
pueda instanciar la clase. Y para terminar hemos creado una propiedad de solo lectura con la que se
puede acceder a la instancia creada. Pero ésta no será Thread-safe. Para conseguirlo podríamos
modificar la clase de la siguiente forma:


Al crear el atributo que almacena la instancia como readonly, y al ser estática, se instanciará al arrancar
la aplicación. Así conseguiremos que sea una clase thread-safe. Es decir, que no habrá problemas si
varios procesos acceden a esta clase al mismo tiempo. No obstante, si quisiéramos respetar que solo se
instanciara el objeto bajo demanda, deberíamos usar bloqueos:

Gracias al bloqueo ya podremos ejecutar nuestra clase singleton en un contexto multihilo,
instanciándola sólo cuando se ha solicitado la primera vez. A este efecto de carga en diferido se le
denomina en inglés “Lazy Loading”. Y desde la versión 4.0 de la framework .net se nos provee un objeto
que nos ayuda a realizarla: Lazy. Por lo que podríamos simplificar nuestro ejemplo usándolo:




El objeto Lazy ya es de por si thread-safe y en su declaración simplemente debemos indicarle de qué
forma se debe instanciar el objeto que contiene. Por esta razón es posiblemente la mejor
implementación del patrón singleton.
Si por ejemplo estuvieramos desarrollando la herramientas de log de nuestra aplicación, bastaría con
que añadieramos las funciones necesarias para escribir en el log a nuestra clase singleton:


Viendo este código en nuestra aplicación, está claro que para poder escribir en el log desde cualquier
punto de la misma sólo tendremos que hacer esta llamada:



Al pararnos a pensar las consecuencias de escribir este código, caeremos en la cuenta de que singleton
nos está creando una dependencia en todo el programa donde queramos tener información del proceso
en forma de logs (eso es a lo largo de toda la aplicación). Algo que comunmente conocemos
como acoplamiento entre clases.

El acoplamiento puede dar varios problemas a lo largo del ciclo de vida de un software. Como por
ejemplo a la hora de realizar pruebas unitarias. Pero no es objeto de este artículo centrarse en este
problema. Aunque si lo es proponer soluciones de implementación del patrón singleton que se adapten
a un desarrollo sólido.

Si quisieramos evitar este acoplamiento, es recomendable usar un IoC Container (Inversion Of Control
Container) para respetar la “D” de los pincipios SOLID: Dependency Inversion Principle. Esta, por así
llamarla, norma nos dice que debemos depender de las abstraciones (las interfaces, los contratos) no
de las concreciones (clases que implementan esas interfaces).

En las frameworks de inversión de control más conocidas se han implementado mecanismos que nos
permiten crear objetos singleton desde el propio contenedor. Esto quiere decir que simplemente
tendríamos que crear una interfaz y una implementación de la misma, sin preocuparnos de como se
instancia. Visto en forma de código sería esto:



De esta forma, delegaríamos la gestión del ciclo de vida de las instancias al IoC Container que hayamos
decidido. A continuación mostraremos cómo podemos configurar una instancia singleton usando las
frameworks de inyección de dependencias (DI) más conocidas:



Pero esto no quiere decir que no nos sirva la implementación de singleton que hicimos anteriormente,
ya que es posible que no nos fiemos o que nuestro contenedor no tenga ningún artefacto que nos
facilite la implementación singleton. Para estos casos, podríamos hacer que un contenedor como Unity
nos devolviera la instancia singleton que gestiona nuestra clase usando la propiedad estática.
Simplemente tendríamos que seguir usando una interface, implementarla en nuestra clase singleton y
registrar una instancia en lugar de una clase en el contenedor:

De esta forma, por ejemplo, si usamos el contenedor de Unity, tendríamos que registrar su valor así:

Con este código sería nuestro singleton Logger quien gestione el ciclo de vida y conseguiríamos
desacoplarnos de la implementación gracias al IoC.

Podríamos hacer lo mismo con Structure maps:


Y para finalizar, con Ninject:

A lo largo de este artículo hemos visto diferentes formas de implementar el patrón singleton. Un patrón
de desarrollo sigue siendo vigente y válido. Lo único que tenemos que tener en cuenta, es evitar
aplicarlo donde no corresponde o de una forma incorrecta. Algo que conocemos como el antipatrón
singletonitis. (programandonet, s.f.)













Conclusión.

Singleton es uno de los patrones más fáciles de entender y manipular lo único que tenemos
que tener en cuenta, es evitar aplicarlo donde no corresponde o de una forma incorrecta. Algo
que conocemos como el antipatrón singletonitis
Recomendaciones

Estimado lector al culminar con este trabajo puedo recomendar que:
Cuando se utilizan patrones de diseño para la resolución de problemas o para la creación de un
software los resultados que se obtienen son extremadamente favorables ya que son soluciones
que han sido probadas por en muchas situaciones similares.
Es necesario tener el conocimiento sobre los diversos patrones de diseño que existen para
seleccionar el más adecuado a la hora de dar soluciones a problemas.


















Bibliografía
http://msdn.microsoft.com. (s.f.). Obtenido de http://msdn.microsoft.com:
http://msdn.microsoft.com/es-es/library/bb972272.aspx#m21
programandonet. (s.f.). http://programandonet.com. Obtenido de http://programandonet.com:
http://programandonet.com/web/patrones-diseno-singleton/