Hola Sebastian! Gran pregunta.... El tema es que en objetos, siempre estamos comunicando instancias. Un objeto A puede necesitar comunicarse con un objeto B. Como consigue el objeto A una referencia a B. De varias formas: alguien se lo pasa como parametro, en un metodo, o alguien se lo paso como parametro en un constructor, o hay una referencia a B en algun lugar estatico, o el propio A lo crea a B, por ejemplo con un new B(). Tambien estan las mismas variantes, pero con FB, una factoria de B: A puede tener una referencia a FB y luego a FB le pide un B.
Pero todo esto, de alguna forma, delega a alguien la creacion de un new B en algun momento y en algun punto del codigo. Con una factoria, se podria crear un new B2(), o new B3(), instancias de subclases de B, o de clases que implementen la misma interface que B, etc.... Pero aun asi, hay casos que el tipo de B es cambiable. De ahi la aparicion del Dependency Injection (A depende de B, pero alguien le inyecta con cual B trabajar). Asi que el patron se aplica, cada vez que A tiene que trabajar con B, pero no sabes de antemano con que tipo especifico de B vas a trabajar. Lo mismo se extiende si B es un simple parametro para A (ejemplo: A es una factoria de conexiones, B es el string de conexion). De ahi, a cuando es bueno usar un patron, esa es una pregunta mas grande. Como todo patron, su uso depende del contexto. Pero podriamos apuntar que el DI permite, por ejemplo, que A, digamos un Entity o Service en la terminologia DDD, se comunique un repositorio B, y alguien le de ese B. Alguna vez le damos B1 (un repositorio que trabaja todo en memoria), otras veces le damos un B2 (un repositorio que va a un DAL nuestro), otras veces un B3 (un repositorio que va contra un ORM). Y en todos esos casos, A nunca toma la decision. El sistema DI (de los cuales pico container, hivemind, spring framework son exponentes en Java, y hasta el mitico AjFramework lo usa de alguna forma.... :-)...:-), nos permite hacer esos "juegos". Estoy escribiendo rapido, mientras actualizo documentos de User Stories, hago un cambio de Team Foundation Server, pienso en el lema de Urysohn para conseguir la metrizacion de espacios topologicos normales, analizo los adjuntos en categorias genericas, y medito sobre algun parrafo de Ser y Tiempo de Heidegger, y leo alguna critica que le hace Ingenieros... si, hoy me olvide de tomarme la pastilla verde... :-) Hoy estoy con la nena... (aclaraciones en http://ajlopez.zoomblog.com/archivo/2006/12/09/estoy-con-la-nena.html) No se si se entendio algo.... Che, no crossposting, preguntar primero en una lista, y si no hay respuesta, preguntar en otra..... Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ ----- Original Message ----- From: Sebastian Renzi To: patrones List Member Sent: Thursday, December 14, 2006 10:52 AM Subject: [patrones] Inversion of Control and Dependency Injection Buenos días lista, en la lista de DDD mandaron unos links sobre el tema del subject, cuando empecé a leer me di cuenta que es un tema que tiene mucha info para leer, pero me gustaría saber en la practica específicamente cuando surge esta necesidad, en que casos es bueno usar este patrón. Tengo entendido que los chicos de Cooperator habían dicho que usaban este patrón dentro de su framework. Gracias Sebastian Renzi
