Muestra las diferencias entre dos versiones de la página.
patrones:di [2013/09/06 18:27] admin creado |
patrones:di [2014/09/09 09:24] (actual) admin [Inyección de Dependencias] |
||
---|---|---|---|
Línea 1: | Línea 1: | ||
====== Inyección de Dependencias ====== | ====== Inyección de Dependencias ====== | ||
+ | La [[wpes>Inyección_de_Dependencias|Inyección de Dependencias]] es un patrón de diseño que ha ido ganando , en la última década (( Mi opinión personal es que la Inversión del control y la Inyección de Dependencias se empezaron a popularizar con la publicación del libro [[http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764543857.html|Expert One-on-One J2EE Design and Development]] escrito por Rod Johnson, creador de Spring, y por el artículo de Martin Fowler [[http://www.martinfowler.com/articles/injection.html|Inversion of Control Containers and the Dependency Injection pattern]] )), mucha aceptación entre los programadores , especialmente en la comunidad Java. | ||
+ | |||
+ | La Inyección de Dependencias es parte de un concepto mas amplio llamado //Inversión del control// , aunque en mucha gente los suele utilizar como sinónimos.Para simplificar la explicación nosotros también vamos a tratarlos como cosas equivalentes aunque sea un concepto erróneo . | ||
+ | |||
+ | La Inyección de Dependencias ( o la Inversión del control) se basa en que, en vez de que una clase vaya a buscar los objetos que necesita llamando a métodos que se los proporcionan, se hace al reves, siendo estos últimos los que se asignan automáticamente al objeto. | ||
+ | |||
+ | <note tip>Para conseguir la Inyección de Dependencias lo más normal es que tengamos un framework que nos permite automatizar y simplicar la tarea.</note> | ||
+ | |||
+ | Antes de ver el código Java vamos a poner un par de ejemplos cotidianos sobre el concepto de Inversión del control: | ||
+ | * En vez de ir a una oficina a que te hagan un seguro para el coche, que sea el agente de seguros el que viene a tu casa para hacerte el seguro. | ||
+ | * Cuando después de pasar una noche con una chica que acabas de conocer y que te ha gustado, le dices que la llamarás al día siguiente y ella te contesta, //no te preocupes ya te llamaré yo//. | ||
+ | * Si en vez de ir a tu al médico cuando estás enfermo , es el médico el que viene a tu casa. | ||
+ | |||
+ | Como podemos ver , los resultados son prácticamente lo mismo si hacemos las cosas de forma //normal// o invertimos la forma de hacerlo (( Aunque no está muy claro es si al final la chica te llamará :-) )). | ||
+ | |||
+ | Veamos el siguiente código Java: | ||
+ | <sxh java> | ||
+ | public class PruebaIoC { | ||
+ | ProfesorDAO profesorDAO=new ProfesorDAOImplHibernate(); | ||
+ | SessionFactory sessionFactory=HibernateUtil.getSessionFactory(); | ||
+ | } | ||
+ | </sxh> | ||
+ | * Línea 1: Para crear el objeto del interfaz ''ProfesorDAO'' usamos la orden ''new'' e indicamos el nombre de la clase que implementa el interfaz que es ''ProfesorDAOImplHibernate'' | ||
+ | * Línea 2: Para crear el objeto del interfaz ''SessionFactory'' usamos el método estático ''getSessionFactory()'' de la clase ''HibernateUtil''. | ||
+ | |||
+ | ¿Cual son los problemas de estas 2 líneas? | ||
+ | Obviamente, la línea ''ProfesorDAO profesorDAO=new ProfesorDAOImplHibernate()'' es bastante lamentable ya que estamos atando el código de ''PruebaIoC'' a una implementación concreta del interfaz ''ProfesorDAO''. Éso se debe evitar a toda costa , aunque una solución es crear otra clase de factoría del interfaz ''ProfesorDAO''. | ||
+ | |||
+ | Ésto nos lleva a preguntarnos , ¿qué tiene de malo la llamada a ''getSessionFactory()''? | ||
+ | |||
+ | Pues que el código de ''PruebaIoC'' está acoplado a la clase ''HibernateUtil'' cuando realmente no la queremos para nada. Lo que ''PruebaIoC'' necesita es un ''SessionFactory'' y no debería saber nada sobre ''HibernateUtil''. ''HibernateUtil'' podría ser subtituida por cualquier otra y no debería afectar nunca a ''PruebaIoC'' ya que no la necesita. | ||
+ | |||
+ | ¿Cómo lo solucionamos? | ||
+ | |||
+ | Pues con la Inyección de Dependencias. La clase quedará ahora de la siguiente manera: | ||
+ | <code java> | ||
+ | public class PruebaIoC { | ||
+ | SessionFactory sessionFactory; | ||
+ | ProfesorDAO profesorDAO; | ||
+ | } | ||
+ | </code> | ||
+ | |||
+ | Vemos cómo ahora sólo se declaran las 2 propiedades. El framework de Inyección de Dependencias que usemos, automáticamente asignará los valores a las 2 propiedades sin que la clase ''PruebaIoC'' sepa de dónde han salido. Es decir, que hemos eliminado las dependencias a ''HibernateUtil'' y hemos evitado incluir en el código la implementación concreta del interfaz ''ProfesorDAO''. | ||
+ | |||
+ | |||
+ | <note tip> | ||
+ | Otra de las ventajas de la Inyección de Dependencias es relativa a las pruebas automáticas pero éste es un tema demasiado amplio en el no nos vamos a meter. Más información se puede encontrar en otro curso que impartí sobre integración contínua en: | ||
+ | * [[http://www.integracioncontinua.es/wiki/doku.php?id=junit:start|JUnit]] | ||
+ | * [[http://www.integracioncontinua.es/wiki/doku.php?id=mockito:start|Mockito]] | ||
+ | </note> | ||
+ | |||
+ | ===== Referencias ===== | ||
+ | * [[http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764543857.html|Expert One-on-One J2EE Design and Development]] | ||
+ | * [[http://www.martinfowler.com/articles/injection.html|Inversion of Control Containers and the Dependency Injection pattern]] |