Se muestra a continuación una nueva entrega de la serie ?Errores comunes en el desarrollo de Software?. En esta ocasión se detalla 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, incluso cuando no se necesitan. Es difícil de detectar hasta que es demasiado tarde para realizar algo para remediarlo. Entre los dificultades que puede ocasionar destacan aumento en el acoplamiento de la aplicación, dificultades de sincronización en aplicaciones multi hilo (threads), alto impacto cuando se requieren modificar, entre otros. A continuación se detallan las características, tipo, dificultades 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 entrada global a ella. El patrón es de utilidad en los casos en los que se requiere un sólo objeto para coordinar las acciones en todo el sistema. La intención es optimizar el rendimiento del sistema formando 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, tiene lugar mucho criticismo hacia su uso y muchos lo estiman un anti patrón. Quienes sostienen esta posición indican que si se emplea excesivamente, se crean restricciones innecesarias en situaciones en las cuales no se requiere una sóla clase. Problemas afiliados con el antipatron Introduce un estado global de la aplicación (Similar a una variable global). Se reduce la probabilidad de paralelismo en proyectos debido a que el entrada al ?Singleton? debe ser serializado. Se incrementa el acoplamiento de fracciónes 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 despues encontrar (al desplegarlo en producción), que para garantizar la escalabilidad deben colocarse en servidores de aplicación separados. La única manera de solucionar el asunto 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). Problema para cambiarlos una vez ya están en producción: El añadir 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 significa probar tanto la clase como el objeto singleton. Soluciones Muchas personas en la comunidad de internet señalan que la sacerdote 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 descubrirse determinado 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 incluso a expensas del mismo rendimiento, dado que limita las probabilidades de paralelismo. La decisión de usar el singleton o no debe tomarse en función de las alternativas: Si se desean limitar los costos de infraestructura de hardware, se utilizará el singleton a expensas de mayores problemas de escalabilidad y mantenimiento. En caso opuesto no usar singleton significa mejores probabilidades 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.