 |
| 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
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"
Fuentes de referencia
Blog Antonio's Home. Singleton
Wikipedia. Singleton
¿Interesado en libros sobre desarrollo de software?
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
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.
>> Entrada de datos manejada inadecuadamente (Input Kludge)>> El botón mágico
>> El Objeto Todopoderoso
>> Errores comunes en el desarrollo de Bases de datos: Tercera Parte
>> Errores comunes en el desarrollo de Bases de datos: Segunda Parte
>> Errores comunes en el desarrollo de Bases de datos
>> Errores comunes de programación: Segunda Parte
>> 5 errores comunes de programación
>> El Objeto Todopoderoso
>> Errores comunes en el desarrollo de Bases de datos: Tercera Parte
>> Errores comunes en el desarrollo de Bases de datos: Segunda Parte
>> Errores comunes en el desarrollo de Bases de datos
>> Errores comunes de programación: Segunda Parte
>> 5 errores comunes de programación
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
>> Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software
>> Ambientes de pruebas integrales de software: Buenas prácticas
>> Ambientes de desarrollo de software: Buenas prácticas
>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)
>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución
>> Ambientes de pruebas integrales de software: Buenas prácticas
>> Ambientes de desarrollo de software: Buenas prácticas
>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)
>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución
No hay comentarios :
Publicar un comentario