Inversion de Control (IoC)

Hace un tiempo atrás convencí a un amigo de que aprendiera Spring, contándole de todas las ventajas que podría lograr utilizando este framework. El comenzó a estudiarlo y como a todos nos ha pasado, le sorprendió la facilidad con la que puede desarrollar aplicaciones.

Hasta ahí todo iba muy bien, pero cuando le pregunte que le pareció la “inversión de control” y la “inyección de dependencia”, me dijo que lo único que entendía era que Spring utilizaba estos patrones…...pero de que se trataba……ni idea!!!!

Así que mi querido amigo XXX (no te voy a echar al agua)…...este post es para ti.

Imaginemos que tenemos una clase “Componente” que necesita usar la clase “Servicio”. Una solución para esto podría ser :

package dukechile.jug.ioc.paso1;<br /><br />public class Servicio {<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio";<br /> }<br /><br />}

package dukechile.jug.ioc.paso1;<br /><br />public class Componente {<br /><br /> private Servicio servicio;<br /><br /> public Componente(){<br /> servicio = new Servicio();<br /> }<br /><br /> public void ejecutarServicio(){<br /> String mensaje = servicio.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso1;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.ejecutarServicio();<br /> }<br /><br />}

El problema de esto es que estamos acoplando las clases. Qué pasaría si por algún requerimiento, el desarrollador modifica el código, solicitando ahora algún parámetro en el constructor de la clase “Servicio”?. Esto nos llevaría no solo a modificar el código de la clase “Servicio”, sino también el de la clase “Componente”.

O pero aun, tu jefe te dice que no le gusta como esta implementada la clase “Servicio”, así que él, en un acto de iluminación divina, desarrollo la clase “Servicio2” la cual (supuestamente) es mejor a la anterior. Por lo tanto, nuevamente tendremos que modificar nuestra clase “Componente”:

package dukechile.jug.ioc.paso2;<br /><br />public class Servicio2 {<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio optimizada";<br /> }<br /><br />}

package dukechile.jug.ioc.paso2;<br /><br />public class Componente {<br /><br /> //private Servicio servicio;<br /> private Servicio2 servicio2;<br /><br /> public Componente(){<br /> //servicio = new Servicio();<br /> servicio2 = new Servicio2();<br /> }<br /><br /> public void ejecutarServicio(){<br /> //String mensaje = servicio.ejecutarServicio();<br /> String mensaje = servicio2.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso2;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.ejecutarServicio();<br /> }<br /><br />}

…..y mejor ni pensemos si alguien se pone original (nunca faltan!!!!) y comience a modificar el constructor de la clase “Servicio2”.

Pero como nada es tan terrible, una solución para estos casos es la “Inversión de control”.

El primer cambio que tendremos que hacer a nuestro código, es olvidarnos de usar “new XXX()”, para lo cual definiremos un método “setXXX” que nos pase una referencia de una instancia de la clase “Servicio2” :

package dukechile.jug.ioc.paso3;<br /><br />public class Componente {<br /><br /> private Servicio2 servicio2;<br /><br /> public Componente(){<br /> }<br /><br /> public void setServicio2(Servicio2 servicio2){<br /> this.servicio2 = servicio2;<br /> }<br /><br /> public void ejecutarServicio(){<br /> String mensaje = servicio2.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso3;<br /><br />public class Servicio2 {<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio optimizada";<br /> }<br /><br />}

package dukechile.jug.ioc.paso3;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.setServicio2(new Servicio2());<br /> }<br /><br />}

Hasta aquí todo va bien, pero que pasaría si nuestro jefe, en un acto de arrepentimiento te dice “evaluando la situación, pienso que debemos volver a usar la clase “Servicio” hasta que nuevo aviso (por no decir, hasta que arregle los errores en mi código)”, y nosotros que ya pensábamos que teníamos casi todo controlado, nuevamente tendremos que volver a cambiar el código de la clase “Componente”, modificando el atributo y el método “setXXX”.

Pero como buenos programadores, sabemos que no va a faltar el jefe original que se le ocurra volver a cambiar el servicio, así que, para evitar problemas a futuro, definiremos una interfaz para el servicio. De ahora en adelante, cualquier clase servicio que se le pase a la clase “Componente”, deberá implementar esta interfaz (ufff….ya no deberemos tocar el código de la clase “Componente”).

package dukechile.jug.ioc.paso4;<br /><br />public class Componente {<br /><br /> private ServicioI servicio;<br /><br /> public Componente(){<br /> }<br /><br /> public void setServicio(ServicioI servicio){<br /> this.servicio = servicio;<br /> }<br /><br /> public void ejecutarServicio(){<br /> String mensaje = servicio.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public interface ServicioI {<br /><br /> String ejecutarServicio();<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public class Servicio implements ServicioI{<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio";<br /> }<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public class Servicio2 implements ServicioI{<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio optimizada";<br /> }<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.setServicio(new Servicio());<br /> componente.ejecutarServicio();<br /> componente.setServicio(new Servicio2());<br /> componente.ejecutarServicio();<br /> }<br /><br />}

Como vemos, cambiar el tipo de servicio en la clase “Componente” ya no tiene impacto en nuestro código!!!! (Obviamente..…hasta que no falte el original que cambie la interfaz!!!).

Hasta aquí toda esta correcto, pero nos falta un pequeño elemento, el “Ensamblador”, cuya tarea principal es obtener la información de cómo cada uno de los elementos debe ser inyectado en otros elementos.

Para estos casos, es donde frameworks como PicoContainer o Spring utilizan el patrón “Inversión de Control”, los cuales se encargan de realizar la inyección de los elementos. El como lo hacen, puede ser a través de código o en un archivo de configuración.

Para el caso de la “Inyección de dependencias” existen tres mecanismos:

• Inyección de Interfaz (IoC tipo 1)
• Inyección de Setter (IoC tipo 2)
• Inyección de Constructor (IoC 3)

Que diferencias existen entre los distintos tipos de inyección, va mas allá de este post, pero el señor Martin Fowler lo explica muy bien en este articulo.

La inversión de control no es la única forma de solucionar este problema, también existe el patrón “Service Locator”, pero eso es tema para otro post.