Clase Singleton vs. estática

Esta es una duda que nos suele surgir muy a menudo a todos… ¿merece la pena desarrollar un Singleton, o me basta con una clase estática? ¿Cual es el enfoque correcto? ¿Es el Singleton la clase estática de los “pijos”, o la clase estática el Singleton de los pobres? La verdad es que como siempre que hablamos de estos temas, suele haber opiniones para todos los gustos… así que contribuiré con una más a que el mundo sea todavía más caótico.


Bueno, como todos sabéis, una clase estática y una singleton tienen, a grandes rasgos, una gran diferencia: la clase Singleton es aquella para la que existe una única instancia accesible por nuestra aplicación y la clase estática es aquella para la que ni siquiera existe instancia (todos sus métodos y miembros son estáticos). Aparentemente sirven para lo mismo, así que… ¿por qué debería usar un Singleton?



  • El principal motivo, a mi entender, es la capacidad que tiene el Singleton de evolucionar hacia una clase que tenga más de una instancia. Puede que no vemos sentido a esto, pero el principio de encapsulación que hay detrás de un Singleton es el mismo que distingue una propiedad de un miembro, o un evento de un delegado. La clase que hace un GetInstance de un Singleton asume que está obteniendo “la instancia” de esa clase, ¡pero nada nos obliga a que esa clase tenga que ser única! Es decir… ¿cúanto nos costaría ampliar el código que os pongo abajo, para añadirle un contador de instancias y permitir un máximo de tres? (lo dejo como ejercicio espiritual para mentes ávidas de pensar). En resumen… un puntito para el Singleton.



    class Singleton
    {


       private static Singleton _instance;


       private Singleton()
       {
       }


       public static Singleton Instance
       {
       
    get
           
    {
              
    if (_instance == null)
               {
                   _instance =
    new Singleton();
               }
              
    return _instance;
            }
      
    }
    }



  • Otra ventaja del Singleton está en que los métodos no son estáticos, y por tanto se pueden sobreescribir en las clases herederas (son “overrideables”). No se puede hacer un override de un método estático. Vamos, que si pretendemos hacer una jerarquía de clases de instancia única, más nos vale que tiremos hacia el singleton… de lo contrario tendremos problemas. Singleton 2, Estática 0

  • La clase Singleton tiene instancia, y eso en sí ya es una ventaja. Por ejemplo, eso nos facilitará que nuestro Singleton pueda implementar interfaces que sencillamente una clase estática nunca podrá implementar. De nuevo, la clase Singleton puede “crecer” con más facilidad que la estática en este sentido. Singleton 3, Estática 0

  • En cuanto a qué es mejor para implementar una clase Thread Safe, fijaros que básicamente el problema que tenemos es el mismo: si tenemos varios threads modificando miembros de la clase, habrá que sincronizarlos y asegurarnos de que sólo uno es capaz de alterar un miembro cada vez. La clase Singleton tiene una peguilla adicional, y es que tenemos que proteger también el método que obtiene la instancia. No es un gran problema… hay un artículo muy interesante de cómo hacerlo AQUÍ. Yo diría que en cuanto a la seguridad de threads, ambas clases “empatan”.

  • Algunos opinan que la clase Singleton es más adecuada para representar clases que mantienen un estado. En realidad esta puede ser más una cuestión de gusto (buen gusto, se entiende) que un requisito real. Ambas clases pueden contener perfectamente un estado. De nuevo otro empate.

  • ¿Y dónde gana la clase estática? En su simplicidad. Así que como el “Keep it Simple” es un argumento que vale por tres, ¡digamos que Singleton y clase estática empatan a puntos! Singleton 3, Estática 3

Vamos, que la idea con la que nos debemos quedar es que una clase Singleton va a hacer nuestro programa un pelín más difícil de comprender, así que como todo, es un recurso que sólo debemos utilizar si es necesario. Y yo, como siempre, que sigo sin mojarme… ¿quieres mojarte tú? ¡¡pues mándame tus comentarios!! Los espero ansioso.

8 comentarios en “Clase Singleton vs. estática”

  1. De acuerdo en casi todo… singleton es para lo que es, y no hay que abusar de ella por muy “cool” que sea decir que usas patrones.

    Hace no demasiado tiempo, un gran experto en la materia que hay por Madrid, me comento sobre los problemas de gestión del ciclo de vida de las clases singleton. Es algo muy dificil de controlar, porque claro, no mueren, y siempre estan activas. Asi que el numero de las mimas debe ser lo mas reducido posible.

    En mi caso, generalmente las suelo utilizar como recursos de configuración o datos “pregenerados” en aplicaciones, al estilo de MiAplicacion.Configuration….

    Muy bueno, Gorka!! Para cuando una sesión de BI en Artalde o Mad.NUG???

  2. ¡Qué tal va eso, Miguel!

    ¡Si parece que fue ayer la última vez que te vi! Vaya… si fue ayer…

    En fin, el tema del BI llegará, y aunque sólo sea por aburrimiento, conseguiré que los asistentes a las charlas de Artalde voten por mi tema 🙂

  3. Una muy buena exposición 🙂

    Por cierto, tres puntos para tí por lo del “keep it simple”. Un gran lema que tengo escrito en la pared de mi dormitorio (las cosas de un piso de estudiante XD).

  4. Sí, ya ves, Ibon, … si sigo en esta progresión a lo mejor acabo siendo el nuevo “spammer de posts” de geeks, aunque en eso, es muy dificil desbancar a Rodrigo! 🙂

  5. Muy buena disquisición. Es la primera vez que ingreso y me sorprendio la claridad de tus explicaciones.
    Soy estudiante de 4º año de Ing. en Sistemas en Argentina y a veces los profesores la complican más de la cuenta, inutilmente.

  6. Yo también estoy de acuerdo.

    Enhorabuena, me ha gustado mucho tu exposición.
    Se trataba de una duda que tenia que se ha disipado por completo.

    Trabajo en J2EE desde hace 4 años y estoy preparando un curso sobre Frameworks y struts.

    Un Saludo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *