Control de la dependencia invertida por patrones inyectables en el contenedor.

Perdón por el título, pero se me hace muy difícil traducir el título del artículo Inversion of Control Containers and the Dependency Injection  Pattern de Martin Fowler.

El caso es que en la Chuwiki he empezado a hacer una traducción al cristiano de este artículo de Contenedores de Inversión de Control y el patrón de inyección de dependencias … ¡¡buff!! … titulito.

Aunque el artículo es muy largo, voy a tratar de hacer aquí un pequeño resumen en cuatro líneas, o alguna más. La idea es la siguiente:

Supongamos que una clase A para realizar su trabajo necesita unos datos. Esos datos se los pide a una  clase B que los lee de un fichero. La forma directa de realizar esto es que la clase A haga un new de la clase B. Esto, sin embargo, hace que la clase A sea menos reutilizable, ya que depende totalmente de la clase B y sólo podrá leer los datos de un fichero en el formato que entiende la clase B.

Este patrón de inyectables nos dice que hagamos una interfaceB con los métodos interesantes de la clase B y hagamos que la clase B implemente esa interfaceB. Por otro lado, la clase A en vez de hacer directamente el new de B, recibe en algún método -el constructor o un método set()- la interfaceB. De esta forma, alguien fuera de la clase A hace el new de B y se lo pasa a A. Haciéndolo así, si algún día cambiamos el formato del fichero o bien deseamos leer los datos de una base de datos, sólo tendremos que hacernos una clase OtraB que implemente la interrfaceB y pasársela a A. La clase A, sin tocar su código, será capaz de leer los datos del nuevo fichero o de la base de datos.

A esto lo llama inversión de control o inyección de depedencia. En vez de ser la clase A la que decide de quien depende, alguien desde fuera le "inyecta" la dependencia a través de un método set().

Y eso es todo.

El resto del artículo se extiende en contarnos que muchos de los frameworks actuales, como Spring, PicoContainer o Avalon, se basan en esto. Esos framework se encargan de instanciar las clases A y B y de pasarle a A la clase B. Todo ello desde código o desde un maravilloso fichero de configuración en donde se les dice qué tienen que instanciar y qué tienen que pasar a quien.

El artículo también menciona otra forma de conseguir todo esto, que es por medio de un localizador de servicios, pero viene a ser lo mismo, aunque metiendo otra interface y otra clase por medio. La idea es que haya una interfaceLocalizador con un método getInterfaceB() que devuelve la InterfaceB. Y es esa InterfaceLocalizador la que le pasamos a A.

No sé, la verdad es que a mi todo esto en realidad me parece un simple patrón Estrategia, pero adornado. Y la verdad, es que el patrón estrategia me ha parecido que no es más que el polimorfismo de cualquier lenguaje orientado a objetos.

Esta entrada fue publicada en diseño. Guarda el enlace permanente.

2 respuestas a Control de la dependencia invertida por patrones inyectables en el contenedor.

  1. rfilgueiras dijo:

    Un comentario sobre el patrón estrategia. Para ti no es más que polimorfismo. Para mi también es «utiliza interfaces en tu diseño».

  2. Marcos dijo:

    Yo ya lo he utilizado (se me ocurrio asi de la nada), pero al final decidi que la clase A disparara un evento en el que pide se le provea de la informacion necesaria, y listo… al final a mi jefe no le gusto :(, lo mismo que cuando por primera vez vio que utilice la referencia al metodo que le proveera de la informacion a A.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.