IoC y el patrón Factory

IoC y el patrón Factory , o, ¿Porqué lo llaman IoC cuando quieren decir repositorio de objetos?

El objetivo de este post es relacionar el concepto IoC con el patrón Factory y presentar un ejemplo de aplicación, pero no define con detalle que es, ni tampoco explica ninguno de los numerosos frameworks que hay para ello (Unity, Spring.Net, Ninject, Windsor, y alguno más que me dejo...).

Siguiendo la linea habitual de este blog, no prentendo ni  voy a tratar de explicar que es IoC, así me evito que nadie me entienda (no os sintáis ofendidos, yo tampoco me entendería), voy a exponer un ejemplo de cómo aplicar el patrón en el que se aprecia su relación con el patrón Factory.

Bien, para mi, a groso modo, IoC en el contexto de inyección de depencencias, es simplemente un repositorio de creación (instanciación) de objetos, fuera de este contexto es otra cosa (quizás algún día decida hacer un post sobre esto), sin embargo la moda a día de hoy es hablar de IoC en este contexto, y cómo este es un blog moderno, pués es de lo que vamos a hablar.

¿Y cómo se crea un repositorio de creación de objetos?, pues fácil, aplicando el patrón Factory, así que, si queremos jugar a reinventar la rueda, divertirnos un poco, y de paso, entender lo que estamos haciendo cuando usamos IoC (En el contexto de inyección de dependencias), te invito a que le eches un vistazo. Por contro si lo que buscas es un framework IoC, pues te reecomeniendo que te mires Unity, Ninject o Spring.NET.


Bien, para no hacer tropocientas lineas de código pongo un ejemplo facilito y conceptual del tema. Para entenderlo se asume que estas familiarizado con las interfaces, y el concepto de inyección de dependencias.

Dada una interfaz de objetos:
  public interface InterfaceX

, y una clase Y, que necesita usar un objeto de la InterfaceX, y a la que queremos aplicar inyección de dependencias

   public class Y{
       public InterfaceX data { get; set; }
       public Y()
       {
            //aplicar IoC con el método GetObject
            //de la clase FactoryObjects_InterfaceX definida abajo
            data = FactoryObjects_InterfaceX.GetObject("ClaseX1");
       }
   }

, Si construimos una clase estática como la que pego abajo, ya estamos aplicando IoC a través del patrón Factory, sin usar ningún framework, y dicho sea de paso reinventando la rueda.

 public static class FactoryObjects_InterfaceX
    {
        public static InterfaceX GetObject(string ObjectName)

        {
            switch (ObjectName){
                case "ClaseX1":
                    return new ClaseX1();
                default:
                    break;

            }
            return new ClaseXDefault();
        }
   }

Observar que lo único que se está haciendo es llamar a una factoría de objetos pasándola por parámetro el nombre de una clase para que esta nos devuelva la instancia. Pues bien, a toda esta monserga es a la que hoy en día los posts de Internet llaman IoC,  o DI con IoC,  o IoC con DI, no se ponene de acuerdo, y yo me pregunto, ¿porque tanto llamarlo IoC cuando quieren decir repositorio de objetos? , cómo antes he dicho IoC es un concepto más general del que tal vez me anime a hablar otro día.

En definitiva que para no cumplir con mi promesa inicial, digamos que para mi, "lo que a día de hoy" todos llaman  IoC es:

"Aplicar el patrón factory para instanciar objetos a través de un repositorio centralizado, de esta forma se consigue que en el contexto de una clase, se puedan desacoplar la instanciación de otras clases, consiguiendo así clases más limpias, que, al menos en ese contexto respetan el principio S(Single Responsability) y como consecuencia de ello son mejores para mantener, reutilizar, y probar."

Esto de que se puedan probar es otro tema, digamos que podemos aplicar la técnica descrita y tendremos clases más testeables, lo cual no quiere decir que necesariamente lo vayamos a hacer ni que estemos aplicando TDD, pero al menos estamos aplicando preTDD,  "Desarrollo Guiado Para Que Se Pueda Probar".

¿Has llegado hasta aquí? gracias y enhorabuena.