Una mentira–Inyección de dependencias

Como comentaba en el post anterior, en general tendemos a crear una gran cantidad de infraestructura de código para otorgarnos una, diriamos, posibilidad de flexibilidad a la hora del desarrollo de más código.

El problema radica cuando la infraestructura es más costosa que la solución que brinda, y en la actualidad, así como ha pasado en otras oportunidades, lo que está de moda se sobre usa, haciendo que sea un total despropósito.

De esta forma, los que tenemos varios años desarrollando hemos podido ver como el desarrollo de aplicaciones se ha visto absurdamente atiborrado de DataSets, de XML, de Web Services, de comunicaciones por HTTP, y por supuesto, de patrones de diseño desde los Singleton hasta todo tipo de Factories (Con nombres, sin nombres, con reflection, con singletons adentro, y un largo etc.), pasando por la joya actual, la inyección de dependencias. Al punto de que, como pasa en todos los casos, se inyectan dependencias hasta para crear un botón en una aplicación de escritorio.

Parte del problema se debe a que los malos programadores seguirán siendo malos programadores por más que apliquen todos los patrones del mundo, por otro por la moda (A quien no le preguntaron en una entrevista de trabajo si alguna vez usó Unity, pero al decir que uno había llegado a crear su propio contenedor dejando de lado Unity y cualquier otra implementación enlatada, y explicando el cómo, el interlocutor ponía cara de estar escuchando a alguien hablando Klingon) lo que lleva a que la IDD sea lo que hay que usar, así que usémoslo en todos lados.

Pero, su uso, en general, no soluciona absolutamente nada (Más allá del mal uso). En definitiva, el objetivo que generalmente se busca es el de poder asociar u obtener un objeto en base a su tipo y en base a una configuración externa a la aplicación. Y si bien aparenta ser un paso lógico, en muy pequeñas oportunidades se requerirá hacer un cambio “en caliente” de un conjunto de componentes pre establecidos, más si tenemos en cuenta que practicamente todas las aplicaciones requerirán un re inicio de la misma al intentar cambiar un ensamblado. O sea, en este caso, con una simple Factory se soluciona todo el problema.

Pero no es este el punto que quiero tocar. No nos vamos a poner a discutir el valor de la IDD. Lo que si es atendible es que todo, en lenguajes tipados, caen nuevamente en la necesidad de un tipo para poder funcionar. Ya que una de las búsquedas es lograr cierto desacoplamiento, solo agregamos una capa más para acoplarnos a una firma que se convierte en nuestra barrera restrictiva: “No vamos a poder obtener más que lo que esa firma nos diga que podemos obtener”.

C#

public class IDD
{
     [Some decoration based on the framework]
     public IDependency dependency { get; set; }

     public Account GetTheAccountForEntity<T>(T entity)
     {
          //Works
          dependency.GetName();

          if (typeof(T) == typeof(Company))
          {
               //Ha ha! Error ahead!
               dependency.CalculateBalance(entity);
          }
          else
          {
               dependency.ObtainLastMovements(entity);
          }
     }
}

public interface IDependency
{
     string GetName();
}

public class BasicUser : IDependency { … }

public class Company : IDependency { … }

El caso anterior es hipotético, y posiblemente algo rebuscado (O no) pero sirve para entender el problema. En este caso, si nosotros queremos crear una función que tenga la capacidad de retornarnos la contabilidad de diferentes “entidades”, sin importar que sean, o sea, desacoplar lo más posible los elementos entrantes, como los objetos que realizarán los cálculos para esas entidades, nos encontramos con que, debido a los tipos obligatorios, o tenemos que sobre escribir código, o crear ramificaciones a niveles más altos para que el código tome un camino diferente y pueda actuar en consecuencia. O sea, aquí no estamos inyectando realmente funcionalidad, ya que la inyección de esa funcionalidad seguirá atada a una ramificación anterior en el código, por lo que, a lo sumo, solo podríamos inyectar funcionalidad diferente para entidades similares. O, en su defecto, nos veremos obligados a elevar la complejidad del código para poder realizar esa simple transacción, o sea, obtener los datos de una función o de otra en base a su tipo.

En el siguiente post veremos como solucionamos esto desde JavaScript al poder estar desacoplados a los tipos.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s