Errores comunes en el desarrollo de software: Singletonitis - La Oficina de Proyectos de Informática

lunes, 31 de diciembre de 2012

Errores comunes en el desarrollo de software: Singletonitis

Imagen de: Wikipedia commons

Se presenta a continuación una nueva entrega de la serie "Errores comunes en el desarrollo de Software". En esta ocasión se describe el anti patron de "Singletonitis", que consiste en el uso abusivo del patrón "Singleton" (Instancia única).

El anti patrón "singletonitis" se manifiesta con el uso excesivo de "singletons" (instancias únicas), en el código, inclusive cuando no se necesitan. Es difícil de detectar hasta que es demasiado tarde para hacer algo para remediarlo.

Entre los problemas que puede ocasionar destacan incremento en el acoplamiento de la aplicación, problemas de sincronización en aplicaciones multi hilo (threads), alto impacto cuando se necesitan modificar, entre otros.

A continuación se describen las características, tipo, problemas ocasionados y la solución del anti patrón de "singletonitis".

El Patrón Singleton y la "Singletonitis"

Consiste en restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto, con la intención de garantizar que una clase sólo tenga una instancia y proporcionar un único punto de acceso global a ella.

El patrón es de utilidad en los casos en los que se necesita un sólo objeto para coordinar las acciones en todo el sistema. La intención es optimizar el rendimiento del sistema creando un sólo objeto, restringiendo la instanciación indiscriminada del mismo objeto.

Si bien es cierto que el patrón singleton optimizar el uso de recursos del sistema, existe mucho criticismo hacia su uso y muchos lo consideran un anti patrón. Quienes sostienen esta posición indican que si se utiliza excesivamente, se crean restricciones innecesarias en situaciones en las cuales no se necesita una sóla clase.

Problemas asociados con el antipatron
  • Introduce un estado global de la aplicación (Similar a una variable global).
  • Se reduce la posibilidad de paralelismo en programas debido a que el acceso al "Singleton" debe ser serializado.
  • Se incrementa el acoplamiento de partes de la aplicación que no deberían estar acompladas: Por ejemplo, imaginese una aplicación Java en la cual se construye un singleton a ser compartido entre los Servlets y EJBs, para luego descubrir (al desplegarlo en producción), que para garantizar la escalabilidad deben colocarse en servidores de aplicación separados. La única forma de solucionar el problema sería con una revisión (manual) completa del código.
  • Uso de métodos privados y estáticos, los cuales son considerados un anti patron (inyección de dependencia).
  • Dificultad para cambiarlos una vez ya están en producción: El agregar un sólo parámetro puede implicar un verdadero dolor de cabeza, con cambios y pruebas necesarias en toda la aplicación.
  • Dificulta la ejecución de pruebas unitarias: Probar cada clase implica probar tanto la clase como el objeto singleton.

Soluciones

Muchas personas en la comunidad de internet señalan que la cura de la Singletonitis es "No usar singletons", esto puede ser un punto de polémica, pués el "Singleton" es considerado por algunos como un patrón y por otros como un anti patrón.

¿Puede encontrarse algún punto intermedio?, el singleton mejora el uso de recursos de la aplicación (consumiendo menos memoria) a expensas de la escalabilidad y mantenimiento de la aplicación, e inclusive a expensas del mismo rendimiento, dado que limita las posibilidades de paralelismo.

La decisión de usar el singleton o no debe tomarse en función de las alternativas: Si se quieren limitar los costos de infraestructura de hardware, se utilizará el singleton a expensas de mayores dificultades de escalabilidad y mantenimiento. En caso contrario no usar singleton implica mejores posibilidades de escalabilidad y mantenimiento, sin embargo los recursos para hardware deberán ser mayores y se incrementaran en proporción con el número de usuarios.

¿Y Que opina usted?

Que opina usted del anti patrón?, ¿lo ha encontrado alguna vez?, ¿Que alternativas consideraría? ¿Que le diría a sus programadores para que no cometieran este error?.

Le invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” (http://www.pmoinformatica.com) y a suscribirse al blog por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica, a nuestra página de Facebook o al feed RSS.

<< Artículo anterior: Base de datos como comunicador de procesos

Artículos de la serie "Errores comunes en el desarrollo de software"

¿Quiere saber más sobre errores comunes de programación, le invitamos a revisar otros artículos de esta serie en el blog.



Fuentes de referencia

Blog Antonio's Home. Singleton

Wikipedia. Singleton



¿Interesado en libros sobre desarrollo de software?



























Transact SQL-DML Funciones y Bases 
de datos
Autor: Rocío Navarro Lacoba
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Código Limpio
Autor: Robert C. Martin
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Métodos ágiles y Scrum
Autor: Alonso Alvarez García y otros
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Code Complete
Autor:
Steven C. McConnell
>> España (amazon.es)
>> Latinoámerica (amazon.com)


Novedades Amazon

¿Interesado en otros productos amazon sobre Gestión de Proyectos y Desarrollo de Software?.

>> Sección de Productos Amazon

Otros artículos en “La Oficina de Proyectos de Informática”

Gestión de desarrollo de software

>> 5 Herramientas para la automatización de pruebas de software

No hay comentarios :

Publicar un comentario

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.