Ha habido varias preguntas ya publicado con preguntas específicas acerca de la inyección de dependencia, tales como cuándo usarlo y lo de marcos hay para ello. Sin embargo,
¿Qué es la inyección de dependencia y cuándo/por qué debería o no debería ser usado?
La mejor definición que he encontrado hasta ahora es uno por James Shore:
"Inyección de dependencias" es de 25 dólares por un término de 5 centavos concepto. [...] La inyección de dependencia significa dar un objeto de sus variables de instancia. [...].
Hay un artículo de Martin Fowler , que podría resultar útil también.
La inyección de dependencia es, básicamente, ofrecer a los objetos que un objeto necesita (sus dependencias, en lugar de tener que construir la misma. Es una técnica muy útil para las pruebas, ya que permite a las dependencias para ser escarnecido o auxiliar.
Las dependencias pueden ser inyectados en los objetos a través de varios medios(inyección de Constructor Setter injection). Uno puede incluso utilizar especializados de inyección de dependencia de los marcos(por ejemplo, Spring Framework) para hacerlo, pero ciertamente no son necesarios. Usted no necesita esos marcos a tener la inyección de dependencia. Crear instancias y transferencia de objetos (dependencias) de forma explícita que es tan bueno como una inyección como la inyección por un marco.
Básicamente, en lugar de tener los objetos de la creación de una dependencia o pidiendo una fábrica de objetos para hacer que uno de ellos, de pasar de la dependencia necesaria en el constructor, o a través de la propiedad de incubadoras, y que lo hacen de otro problema (un objeto más arriba en el gráfico de dependencia, o una dependencia del inyector que se construye el gráfico de dependencia). Una dependencia como la que estoy usando aquí es cualquier otro objeto el objeto actual para sostener las necesidades de una referencia.
Una de las principales ventajas de la inyección de dependencia es que se puede hacer prueba de mucha más fácil. Supongamos que tenemos un objeto que en su constructor hace algo como:
public SomeClass() {
myObject = Factory.getObject();
}
Esto puede ser problemático cuando todo lo que quiero hacer es ejecutar algunas pruebas de unidad en SomeClass, especialmente si myObject es algo que hace complejo el disco o el acceso a la red. Así que ahora usted está buscando en la burla myObject pero también de alguna manera la interceptación de la fábrica de llamada. Duro. En su lugar, pase el objeto como argumento al constructor. Ahora que te has trasladado el problema a otro lugar, pero la prueba puede llegar a ser mucho más fácil. Acaba de hacer un muñeco myObject y pasar en. El constructor de ahora tendría que mirar un poco como:
public SomeClass (MyClass myObject) {
this.myObject = myObject;
}
La mayoría de la gente probablemente el trabajo de los otros problemas que pueden surgir cuando no se utiliza la inyección de dependencia, mientras que las pruebas (como las clases que hacer mucho trabajo en sus constructores, etc.) La mayoría de esto es lo que he recogido en el Google las Pruebas de Blog, para ser perfectamente honesto,...
He encontrado este curioso Ejemplo en términos de sueltas de acoplamiento:
Cualquier aplicación que se compone de muchos objetos, que colaboran entre ellos para realizar algunas cosas útiles. Tradicionalmente, cada objeto es responsable de la obtención de sus propias referencias a los objetos dependientes (dependencias) colaborar con el. Esto lleva a que muy junto clases y duro-para-el código de la prueba.
Por ejemplo,considere un Car objeto.
Un Car depende de Ruedas, Motor, Combustible, Batería, etc para que se ejecute. Tradicionalmente se define la marca de tales objetos dependientes, junto con la definición de la Car objeto.
Sin la Inyección de dependencias (DI) :
class Car{
private Wheel wh= new NepaliRubberWheel();
private Battery bt= new ExcideBattery();
//rest
}
Aquí, la Car objeto es responsable de la creación de los objetos dependientes.
¿Y si queremos cambiar el tipo de su objeto dependiente - digamos Wheel - después de la inicial NepaliRubberWheel()pinchazos?
Tenemos la necesidad de volver a crear el objeto de Automóvil con su nueva dependencia decir ChineseRubberWheel(), pero sólo el Car fabricante puede hacer que.
Entonces lo que el Dependency Injection nos hace para ...?
Cuando se utiliza la Inyección de Dependencia, los objetos son dados sus dependencias en tiempo de ejecución en lugar de tiempo de compilación (coche el tiempo de confección).
Así que ahora podemos cambiar la Wheel cuando queramos. Aquí, la Dependency (Wheel) puede ser inyectado en Car en tiempo de ejecución.
Después de usar DI:
class Car{
private Wheel wh= [Inject an Instance of Wheel at runtime]
private Battery bt= [Inject an Instance of Battery at runtime]
}
La Inyección de dependencia es una práctica donde los objetos están diseñados de una manera donde reciben las instancias de los objetos de otras piezas de código, en lugar de construir internamente. Esto significa que cualquier objeto que implementa la interfaz, la cual es requerida por el objeto puede ser sustituido sin necesidad de cambiar el código, lo que simplifica la prueba y la mejora de la disociación.
Por ejemplo, considere las siguientes clases:
public class PersonService {
public void addManager( Person employee, Person newManager ) { ... }
public void removeManager( Person employee, Person oldManager ) { ... }
public Group getGroupByManager( Person manager ) { ... }
}
public class GroupMembershipService() {
public void addPersonToGroup( Person person, Group group ) { ... }
public void removePersonFromGroup( Person person, Group group ) { ... }
}
En este ejemplo, la aplicación de PersonService::addManager y PersonService::removeManager tendría una instancia de la GroupMembershipService para hacer su trabajo. Sin la Inyección de Dependencia, la forma tradicional de hacer esto sería una instancia de un nuevo GroupMembershipService en el constructor de PersonService y el uso que un atributo de la instancia en ambas funciones. Sin embargo, si el constructor de GroupMembershipService tiene varias cosas que requiere, o peor aún, hay algunos de inicialización de "incubadoras" que necesitan para ser llamado en la GroupMembershipService, el código se crece con bastante rapidez, y el PersonService ahora no sólo depende de la GroupMembershipService pero también todo lo demás que GroupMembershipService depende. Por otra parte, la vinculación a GroupMembershipService está codificado en la PersonService lo que significa que usted no puede "dummy" una GroupMembershipService para propósitos de prueba, o utilizar un modelo de estrategia en diferentes partes de la aplicación.
Con la Inyección de Dependencia, en lugar de crear instancias de la GroupMembershipService dentro de su PersonService, tendría que pasar a la PersonService constructor, o bien agregar una Propiedad (getter y setter) establecer una instancia local de la misma. Esto significa que su PersonService ya no tiene que preocuparse acerca de cómo crear un GroupMembershipService, que sólo acepta a los que es dado, y colabora con ellos. Esto también significa que todo lo que es una subclase de GroupMembershipService, o implementa la GroupMembershipService interfaz se puede "inyectar" en la PersonService, y el PersonService no se necesita saber acerca de el cambio.
La aceptación de respuesta es buena - pero me gustaría añadir a esto, que el DI es muy parecido al clásico evitando de codificado constantes en el código.
Cuando se utilizan algunas constantes, como una base de datos nombre que había de mover rápidamente desde el interior del código de algún fichero de configuración y pasar una variable que contiene el valor hasta el lugar donde se necesita. La razón para hacerlo es que estas constantes suelen cambiar con más frecuencia que el resto del código. Por ejemplo, si te gustaría probar el código en una base de datos de prueba.
DI es análoga a la presente en el mundo de la programación Orientada a Objetos. Los valores que en lugar de constantes literales son objetos completos - pero la razón para mover el código creando desde el código de la clase es similar a los objetos cambian con mayor frecuencia, a continuación, el código que utiliza. Un importante caso de que tal cambio es necesario pruebas.
Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.
