Enfermedades del software: Singletonitis

Patrón Singleton en notación UML

De nuevo, una enfermedad del software que a más de uno le va a sorprender. Y sin embargo es muy pero que muy vieja. Al final de esta entrada tenéis unos cuantos ejemplos de fuentes que he utilizado y que me han recordado lo peligroso que es usar patrones sin conocimiento, pero especialmente, el más simple de todos: el patrón Singleton.

¿En qué consiste el patrón Singleton?

Este patrón es el más sencillo, y también uno de los más conocidos y utilizados. Básicamente, su propósito es asegurar que sólo exista una instancia de una clase dada.

Singletonitis, una definición

Bien, dada la definición anterior, el anti-patrón Singleton ha recibido el nombre de "singletonitis": desorden transitorio del programador, que le lleva al abuso del patrón Singleton. Algunos autores van más allá, y definen claramente al patrón Singleton como un verdadero anti-patrón (es más causa de problemas, que solución de ninguno: o como se suele decir, pan para hoy, y hambre para mañana).

En el libro "Refactoring to Patterns", el autor Joshua Kerievsky presenta el término Singletonitis, refiriéndose literalmente a "la adicción al patrón Singleton". Este autor, propone un tipo de refactorización que llama "Inline Singleton", cuyo objetivo es eliminar los Singletons innecesarios en una aplicación.

Hay muchos problemas con el patrón singleton. Demasiados. Algunos de ellos:

• Crea una alta dependencia en el código. Un alto acoplamiento que es fuente de problemas
• Crea problemas con las pruebas y su automatización, especialmente por la alta dependencia del código al tratar de hacer pruebas unitarias.
• Problemas con el multi-hilo y concurrencia.
• Alta probabilidad de crear spaguetti-code, difícil de leer e incluso de debuguear, por acumulación de uno o varios de los anteriores.
• Problemas de reusabilidad. Lo mismo, por acumulación de uno o varios de los anteriores.

En uno de los artículos que he revisado, el autor (Taskinoor Hasan ), ha tratado de hacer una aproximación seria, tratando de dar una solución lógica a los diversos problemas que el autor va detectando en su inocente implementación del patrón Singleton. De tan serio que es el artículo, y la acumulación sucesiva de problemas que presenta, acaba siendo hasta ridículo y divertido.

Del tema de la concurrencia y problemática con los entornos multi-hilo, hay varios artículos que presentan estrategias más o menos eficaces en función de la situación, lo que complica la resolución del problema. Y es que hay que ver lo bonito que es todo cuando en nuestra ignorancia, planteamos un sistema con Singletons creyendo que éstos van a ser instancias mono-uso. Con el paso del tiempo, la experiencia (y la dura realidad), nos van enseñando que al ver las cosas desde un nivel superior, o al tratar de reutilizar componentes, nuestro pequeño patrón Singleton es una fuente de problemas. Además, esos problemas al haber tanto acoplamiento en el código y dificultad de testeo, son complicados de detectar y resolver.

Frases como "esto nunca se va a usar en multi-hilo", tan categóricas, deberían ir siempre acompañadas de un "zas, en toda la boca".

Es duro ver cómo la falta de previsión y el abuso de patrones (patronitis), hace que las cosas se usen fuera de contexto y acaben haciendo todo menos aquello para lo que fueron diseñadas.

Solución: ¿vacuna o erradicación?

No son pocos los autores que defienden la total prevención mediante la erradicación de la causa de la Singletonitis, evitando dicho patrón.
Otros, elaboran complejísimas estrategias para detectar problemas, incompatibilidades, etc. Incluso existe una estrategia de validación dentro del patrón llamada "Double Check Locking", diseñada para evitar que en el caso de multi-hilo, haya problemas derivados de los bloqueos necesarios dentro del patrón.
Yo propongo algo que varios de los autores defienden, y es el uso de otro patrón (que por supuesto tendrá su enfermedad asociada por abuso), y es el de IoC (Inversion of Control).

¿Y tú? ¿Ya has sufrido tu Singletonitis?...

Fuentes:

http://taskinoor.wordpress.com/2011/04/18/singleton_multithreaded/
http://www.antonioshome.net/blog/2006/20060906-1.php
http://pragmaticintegration.blogspot.com.es/2006/02/singletonitis.html
http://www.theserverside.com/discussions/thread.tss?thread_id=42116
http://www.gamedev.net/blog/32/entry-510687-why-are-you-infected-with-singletonitis/
http://msdn.microsoft.com/es-es/library/bb972272.aspx
http://www.teatromagico.net/foro/viewtopic.php?f=4&t=13513&p=454983
Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995.
Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004.
http://weblogs.asp.net/sfeldman/archive/2008/10/22/singletonitis.aspx