Marco teórico: Inversión de control, inversión de dependencias e inyección de dependencia.

Los conceptos de Inversión de Control e Inyección de Dependencias no son nuevos, sino que se remontan hasta finales de la década de los 80. Sin embargo, estos conceptos han comenzado a popularizarse debido a la estrecha relación que mantienen con la aparición de Frameworks como Spring en Java o Unity en .NET.

Inversión de Control

El concepto de Inversión de Control fue acuñado originalmente por Martin Fowler, diseñador del patrón MVVM (Model View View-Model). Fowler definió el concepto de forma informal denominándolo como el Principio de Hollywood, en el que, tras una audición, se le decía al actor la famosa frase de No nos llames, nosotros te llamaremos.

El principio establece una diferenciación entre el concepto de biblioteca y framework, definiendo el primero como un simple conjunto de clases, métodos y funciones que son invocadas por el flujo del programa y que posteriormente devuelven el control a éste (control normal) y el segundo como un diseño más abstracto y elaborado que se encargará, en algún momento, de invocar el código que el programador se encargue de codificar (inversión de control).

El ejemplo expuesto por Fowler no puede ser más sencillo: un control normal sería un simple programa secuencial de consola en el que el programa va solicitando datos al usuario y realizando operaciones (cálculos, visualización por pantalla) al recibir las respuestas. Un programa que aplica una inversión de control, sin embargo, se podría representar como una ventana compuesta por cajas de texto, etiquetas y botones. El Framework, en este caso, expondría un bucle de espera que detectaría la emisión de eventos, como la pulsación de un botón, momento en el cual se ejecutaría el código de usuario. El Framework invocará nuestro código en lugar de realizar la operación contraria.

El Principio de Inversión de Dependencias

El segundo concepto se lo debemos a otro de los gurús de la ingeniería del Software, Robert C. Martin, creador del desarrollo ágil y de los principios básicos de la programación orientada a objetos, denominados SOLID.

Dos de estos principios, de hecho, sirvieron como base para otro de ellos: el concepto de Inversión de Dependencias:

  • Principio Abierto/Cerrado: una entidad software debe ser abierta para su extensión, pero cerrada para su modificación.
  • Principio de Sustitución de Liskov: un objeto siempre debe poder ser reemplazado por una instancia de una clase derivada sin alterar el funcionamiento del programa, es decir, todos los métodos de una clase padre deben estar presentes en una clase hija, y esta debe poder asumir el papel de su padre.

Partiendo de estos principios, Martin escribió un artículo en el que desarrollaría el concepto de Principio de Inversión de Dependencias. En este artículo establece, a grandes rasgos, que uno de los grandes problemas del software es el acoplamiento, es decir, la dependencia de clases entre sí.

Según Martin, las clases de las capas superiores no deberían depender de las clases de las capas inferiores, sino que deberían basarse en abstracciones. Del mismo modo, las clases inferiores deberían cumplir el mismo principio. Del mismo modo, las abstracciones no deberían depender de los detalles, sino que son los detalles los que deberían depender de las abstracciones.

El concepto de inversión proviene, por lo tanto, por el giro de 180 grados que se produce respecto al paradigma habitual en el que los módulos superiores tienden a construirse sobre los inferiores (por ejemplo, una clase de interfaz de usuario invocando un método de una clase de negocio) y en el que las abstracciones tienden a depender de los detalles (por ejemplo, una implementación de una interfaz).

Inyección de Dependencias

Llegamos así al tercer concepto en discordia, relacionado con los dos conceptos anteriores: la inyección de dependencias. Este concepto se basa en hacer que una clase A inyecte objetos en una clase B en lugar de dejar que sea la propia clase B la que se encargue de crear el objeto (éste último caso se suele realizar mediante un simple new()).

La forma más común de realizar la inyección de dependencias es a través de lo que se conoce como Contenedor DI, que se encarga de realizar la inyección en objetos simples (POJOs o POCOs). Es probable que, después de esta escueta explicación, haya quien se plantee la pregunta: ¿qué tiene que ver la inyección de dependencias con el rollo que nos has soltado en los dos apartados anteriores? Principalmente se basa en que la inyección de dependencias se suele realizar a través de algún tipo de Framework (Spring, Unity, Castle Windsor…), por lo que se realizará mediante una inversión de control, haciendo que sea el Framework (concretamente el contendor DI) el que invoque nuestro código.

 

Fuente: https://danielggarcia.wordpress.com/2014/01/15/inversion-de-control-e-inyeccion-de-dependencias/

Deja un comentario