Desambiguación IOC y DI

Desde hace pocos años, con la moda de las buenas prácticas en programación,  SOLID y  TDD, están muy presentes en este escenario los términos IoC y DI(Dependency Inyection o Inyeccción de dependencias) más adelante explico porque tacho este término

Después de leer muchisimos artículos en Internet sobre el tema, interpreto que hay muchísima confusión con estos dos términos; voy a dar mi opinión de porque: Resulta que dentro del contexto de los principios SOLID de la POO, está el principio D, que se llama Inversión(no inyección) de Dependencias y dice que debemos depender de abstracciones, no de concreciones.

En el contexto de una clase, se tiene por norma la siguiente regla basada en este principio:
Nunca instanciar una clase B dentro de una clase A, lo correcto es: 
o bien recibir por parámetro la clase B (o interfaz B)
, o depender de una interfaz de la clase B, pero nunca de una clase concreta

¿Y cómo aplicamos la regla basada en este principio?, pues bien hay dos opciones:

1. Inyectar la clase por el constructor, o también una interfaz, al instanciar la clase pasarle por parámetro el objeto concreto.A esta técnica o patrón se le llama DI (Inyección de dependencias), y debido a su similitud léxica con el principio D(Inversión de dependencias) es la causa de confusión entre los términos, porque el principio es inversión, no inyección, y la técnica o patrón sí que es la inyección.
   En muchos posts sobre el tema leeremos,
   "aplicar el principio de Inyección de Dependencias"
   , pero esto no es correcto, porque el principio es la inversión, no la inyección.
   
   
2. Crear un repositorio de factoría de objetos en el que asociar interfaces con objetos concretos (vease este post), dentro de la clase está permitido llamar al repositorio para obtener objetos, pero nunca instanciar objetos directamente.
   
   Este segundo patrón se puede combinar con el primero puesto que son compatibles, es decir, tener un repositorio de objetos e inyectar a la clase la interfaz. Esto es lo que hacen muchos IoC contaniers (Unity, Ninject, spring.NET, etc...)
   
   En este contexto opino que es correcto llamar al repositorio de objetos IoC, puesto que este es un agente que servirá para instanciar objetos, no será necesario que los instanciemos nosotros, de hecho este término se cita en algunos posts aludiendo al principio de Hollywood ("No nos llame, le llamaremos nosotros")
   
   Opino por tanto que sí que es correcto el uso de este término, aunque puede crear cierta confusión con respecto a lo que IoC significa, ya que IoC es un término que ya se usaba antes en informática y está vinculado al patrón Observer, es decir que cualquier evento se puede decir que está usando IoC, por ejemplo el clic de un botón..., en cualquier caso no es el objetivo de este post discutir sobre este término sino sobre el de DI.

En el contexto de combinación de los dos patrones, podemos encontrar en muchos posts 

"Aplicamos el principio Inyección de Dependencias utilizando IoC"

, púes bien opino que esto no es correcto, que se está definiendo así en muchos posts debido a la confusión del término que he descrito antes, y lo correcto sería decir

"Aplicamos el principio Inversión de Dependencias combinando Inyección de dependencias e IoC"

Bueno, al menos esta es mi opinión sobre porque el uso del principio Inversión de de dependencias se ha confundido con el patrón Inyección, no obstante se aceptan alegaciones en contra.

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.

Grid MVC edit inline

Aquí dejo el link de mi artículo en codeproject.com sobre cómo hacer un grid estilo excel, con edición rápida en linea, utilizando MVC, JQuery y AJAX.

http://www.codeproject.com/Tips/720348/MVC-Grid-Inline-Edit

Art programming

Hola,

 hoy vamos a hablar del Art programming, a ver si mi colega Canx se anima, ahí va una pequeña pieza de arte:

public void AnyFunction(){
    //cosas
    //más cosa
    using(new España()){
    }
    //y más cosas
}

Canx, ¿Sigues?