La cosa es que el Singleton hace dos cosas:
- Se asegura de que sólo haya una instancia del objeto.
-
SomeStuff()
El problema de hacer dos cosas es que viola la S de los principios Solid: Single Responisability Principle. Y esto hace que no sea fácilmente testeable.
Cuando quiero hacer que sea testeable quito el Singleton y lo sustituyo por una factoría, una clase estática y una clase que hace la funcionalidad de SomeStuff.
Aquí tenéis un ejemplo simple:
public static class Singletons
{
private static Factoria fact = new Factoria();
<pre><code> public static void HazLoTuyo()
{
fact.GetUnicaInstancia().DoStuff();
}
</code></pre>
}
public class Factoria
{
private Clase unicaInstancia;
<pre><code> public Factoria()
{
unicaInstancia = new Clase();
}
public Clase GetUnicaInstancia()
{
return this.unicaInstancia;
}
</code></pre>
}
public class Clase
{
public Clase()
{
}
<pre><code> public void DoStuff() { }
</code></pre>
}
De esta manera puedo testear la clase Clase sin preocuparme de que sólo hay una instancia de ella en el sistema.
Es por esto que me asalta la duda, ¿no será el Singleton un antipatron?
¿Cómo lo veis vosotros?
[Update 1]
Gracias a los comentarios voy a ir actualizando el post con algunas conclusiones y dudas que se me plantean.
Resumiendo un poco los comentarios, cuando sólo queremos una instancia de nuestra clase Clase (definida más arriba) suele ser buena idea usar un inyector de dependencias y registrar nuestra clase para que el inyector nos devuelva siempre la misma instancia.
De esta manera “invertimos el control” de la instanciación de nuestra clase, y podemos testearla de manera aislada.
¿Pero que pasa si no queremos meter un inyector de dependencias por el motivo que sea?
Podríamos meter una clase parecida a esta:
public class ClaseFachada
{
private static Clase clase = new Clase();
<pre><code> public static void DoStuff()
{
clase.DoStuff();
}
</code></pre>
}
De esta manera podemos usarla en nuestro código de esta forma:
ClaseFachada.DoStuff();
Como si fuese un Singleton, pero evitando el típico Clase.Instance.DoStuff(). La cosa es que si estamos desarrollando una librería y queremos que nuestra librería se use así.
¿Os parece adecuado? ¿Cómo lo mejoraríais?
juanlao 