Enlaces de interés

Bueno, voy a comenzar con una pequeña colección sobre enlaces que voy encontrando por ahí emulando a un amigo.

Nueve técnicas para transmitir una imagen positiva que te ayude a conectar con la audiencia. El Arte de Presentar.

 

El enésimo post sobre el Singleton (UPDATE 1)

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?

[Evento] Wave Engine University Tour

Wave Engine University TourA partir del 17 de Marzo comenzaremos un Tour que nos llevará por un montón de universidades españolas para enseñar Wave Engine.

Wave Engine es un motor gráfico multiplataforma y gratuito, en continua evolución añadiendo cada día nuevas funcionalidades. Y además soy miembro del equipo de desarrollo :).

El propio equipo será el encargado de impartir el taller para ayudarte a introducirte en el desarrollo de videojuegos o, si ya estás en el mundillo, para enseñarte todo lo que Wave Engine puede aportar a tus juegos y cómo puede facilitarte la vida.

También habrá premios para los que lleguen a publicar juegos en la Store de Windows 8 y/o Windows Phone. Y muchas sorpresas más.

¡NO TE LO PUEDES PERDER! Busca tu ciudad y regístrate aquí.

P/D: Los que me conocéis, sabréis enseguida quién fue la musa del diseñador del cartel ;).

Difundid y  compartid por las redes sociales. Y gritad por la calle que Wave Engine está de gira.

monos alados

PERO SOBRE TODO PARTICIPAD