dependency-injection - injection - inyeccion de dependencias php
Adicción a la inyección de dependencia? (9)
Además, me sentiría mucho mejor si fuera una parte del lenguaje que estaba usando.
Para su información, hay una inyección de dependencia funcional muy simple y como parte de JDK 6. Si necesita una inyección de dependencia liviana y directa, entonces úselo.
Al usar la clase ServiceLoader puede solicitar un servicio (o muchas implementaciones del servicio) basado en una clase:
package dependecyinjection;
import java.util.ServiceLoader;
public abstract class FooService {
public static FooService getService() {
ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);
for (FooService service : loader) {
return provider;
}
throw new Exception ("No service");
}
public abstract int fooOperation();
}
package dependecyinjection;
public class FooImpl extends FooService {
@Override
public int fooOperation() {
return 2;
}
}
¿Cómo define ServiceLoader las implementaciones de servicios que se devuelven?
En la carpeta del proyecto, cree una carpeta llamada META-INF / services y cree un archivo llamado dependencyinjection.FooService . Este archivo contiene una línea que apunta a la implementación del servicio. En ese caso: dependecyinjection.FooImpl
Esto no es ampliamente conocido todavía.
¿Hay un inconveniente? Me siento casi dependiente de eso ahora. Cada vez que un proyecto supera un determinado tamaño, casi se siente una reacción alérgica a los patrones estándar y se vuelve a conectar inmediatamente con un marco de Inyección de Dependencia.
El problema más grande que he encontrado es que puede ser confuso para otros desarrolladores que recién lo están aprendiendo.
Además, me sentiría mucho mejor si fuera una parte del lenguaje que estaba usando. Aunque, para Java al menos, hay un par de bibliotecas muy livianas que son bastante buenas.
¿Pensamientos? ¿Malas experiencias? ¿O simplemente deja de preocuparte por eso?
[EDITAR] Re: descripción de la inyección de dependencia en sí
Lo siento por ser vago. Martin Fowler probablemente lo describe MUCHO mejor de lo que yo podría ... sin necesidad de perder el esfuerzo.
Casualmente, esto confirma un punto al respecto, que todavía no se practica ampliamente y podría tender a ser una barrera cuando se trabaja con equipos si no todos están preparados para ello.
¿Podría agregar un enlace o dos para explicar qué es Dependency Injection, para aquellos de nosotros que estamos jugando en casa? El artículo de wikipedia es entretenido, pero no muy esclarecedor.
@Blorgbeard: http://www.martinfowler.com/articles/injection.html es probablemente uno de los mejores artículos sobre el tema
El único inconveniente que se me ocurre es una pequeña disminución en el rendimiento a través de constantes llamadas virtuales :)
El problema que tengo con DI es el mismo problema que tengo con COM y con cualquier código que se asemeje a algo así:
i = GetServiceOrInterfaceOrObject(...)
El problema es que dicho sistema no se puede entender a partir del código. Debe haber documentación en algún lugar [else] que defina qué servicio / interfaz / objeto puede solicitar el servicio / interfaz / objeto X. Esta documentación no solo debe mantenerse, sino que debe estar disponible tan fácilmente como la fuente.
A menos que el documento esté muy bien escrito, a menudo aún no es fácil ver las relaciones entre los objetos. A veces las relaciones son temporales, lo que hace que sea aún más difícil de descubrir.
Me gusta el principio de KISS, y creo firmemente en el uso de la herramienta adecuada para el trabajo. Si el beneficio de DI, para un proyecto determinado, supera la necesidad de escribir un código comprensible, entonces úsala.
En mi opinión, los principales inconvenientes son la curva de aprendizaje (como usted señala) y la posibilidad de que la abstracción agregada dificulte la depuración (que también es parte de la curva de aprendizaje).
Para mí, DI me parece más apropiado para sistemas más grandes y complejos: para pequeñas aplicaciones puntuales, puede que la aplicación tenga una arquitectura excesiva, básicamente, que la arquitectura requiera más tiempo de desarrollo para cumplirla que alguna vez puede compensar el valor que proporciona.
He analizado algunas de las posibles desventajas en una publicación de blog aquí: http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html
Solo deja de preocuparte por eso. Es mi opinión que con el tiempo las técnicas de IoC serán una segunda naturaleza para la mayoría de los desarrolladores. Estoy tratando de enseñarle a los desarrolladores aquí en el trabajo al respecto y me resulta difícil transmitir el mensaje porque se siente tan antinatural a la forma en que siempre hemos hecho las cosas ... que resultó ser el camino equivocado. Además, los desarrolladores nuevos en IoC y nuevos en un proyecto que encuentro tienen aún más dificultades. Están acostumbrados a usar el IDE para seguir el rastro de las dependencias y obtener una comprensión de cómo todo "se junta". Esa información a menudo se escribe en arcane XML.
Soy grande en IO, sin embargo, vi algunos proyectos con enormes archivos de configuración xml que nadie entiende. Así que ten cuidado con la programación en xml.