design patterns - ventajas - ¿Qué es la inyección de dependencia?




inyeccion de dependencias ventajas (20)

Ya se han publicado varias preguntas con preguntas específicas sobre la inyección de dependencia , por ejemplo, cuándo usarlo y qué marcos de trabajo hay para ello. Sin embargo,

¿Qué es la inyección de dependencia y cuándo / por qué debe o no debe usarse?


¿Qué es la inyección de dependencia?

La inyección de dependencia (DI) significa desacoplar los objetos que dependen uno del otro. Diga que el objeto A depende del objeto B, por lo que la idea es desacoplar estos objetos entre sí. No necesitamos codificar el objeto utilizando una nueva palabra clave en lugar de compartir dependencias con objetos en tiempo de ejecución a pesar del tiempo de compilación. Si hablamos de

Cómo funciona la inyección de dependencia en primavera:

No necesitamos codificar el objeto con una nueva palabra clave, en lugar de definir la dependencia del bean en el archivo de configuración. El contenedor de muelle se encargará de enganchar todo.

Inversión de Control (IOC)

La COI es un concepto general y puede expresarse de muchas maneras diferentes y la inyección de dependencia es un ejemplo concreto de la COI.

Dos tipos de inyección de dependencia:

  1. Inyección Constructor
  2. Inyección de Setter

1. Inyección de dependencia basada en constructor:

El DI basado en constructor se logra cuando el contenedor invoca a un constructor de clase con varios argumentos, cada uno de los cuales representa una dependencia de otra clase.

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2. Inyección de dependencia basada en Setter:

El DI basado en Setter se logra mediante el contenedor que llama a los métodos de establecimiento en sus beans después de invocar un constructor sin argumentos o un método de fábrica estático sin argumentos para instanciar su bean.

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

NOTA: Es una buena regla general usar argumentos de constructor para dependencias obligatorias y configuradores para dependencias opcionales. Tenga en cuenta que si utilizamos una anotación basada en @ La anotación requerida en un configurador se puede utilizar para hacer definidores como dependencias requeridas.


¿La "inyección de dependencia" no significa simplemente usar constructores parametrizados y definidores públicos?

El artículo de James Shore muestra los siguientes ejemplos para comparar .

Constructor sin inyección de dependencia:

public class Example { 
  private DatabaseThingie myDatabase; 

  public Example() { 
    myDatabase = new DatabaseThingie(); 
  } 

  public void doStuff() { 
    ... 
    myDatabase.getData(); 
    ... 
  } 
} 

Constructor con inyección de dependencia:

public class Example { 
  private DatabaseThingie myDatabase; 

  public Example(DatabaseThingie useThisDatabaseInstead) { 
    myDatabase = useThisDatabaseInstead; 
  }

  public void doStuff() { 
    ... 
    myDatabase.getData(); 
    ... 
  } 
}

Imaginemos que quieres ir a pescar:

  • Sin la inyección de dependencia, necesita cuidar de todo usted mismo. Necesitas encontrar un bote, comprar una caña de pescar, buscar un cebo, etc. Es posible, por supuesto, pero te pone mucha responsabilidad. En términos de software, significa que debe realizar una búsqueda de todas estas cosas.

  • Con la inyección de dependencia, otra persona se encarga de toda la preparación y pone a su disposición el equipo requerido. Recibirá ("se inyectará") el bote, la caña de pescar y el cebo, todo listo para usar.


La inyección de dependencia es una práctica en la que los objetos se diseñan de manera que reciben instancias de los objetos de otras piezas de código, en lugar de construirlos internamente. Esto significa que cualquier objeto que implemente la interfaz que requiere el objeto puede sustituirse sin cambiar el código, lo que simplifica las pruebas y mejora el desacoplamiento.

Por ejemplo, considera estas 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 implementación de PersonService::addManager y PersonService::addManager PersonService::removeManager necesitaría una instancia del GroupMembershipService para realizar su trabajo. Sin la inyección de dependencia, la forma tradicional de hacer esto sería crear una instancia de un nuevo servicio de GroupMembershipService en el constructor de PersonService y usar ese atributo de instancia en ambas funciones. Sin embargo, si el constructor de GroupMembershipService tiene varias cosas que requiere o, lo que es peor, hay algunos "configuradores" de inicialización que deben llamarse en GroupMembershipService , el código crece bastante rápido, y PersonService ahora no solo depende de GroupMembershipService sino También todo lo demás que GroupMembershipService depende. Además, el enlace a GroupMembershipService está codificado en el PersonService que significa que no puede " GroupMembershipService " un GroupMembershipService con fines de prueba, o usar un patrón de estrategia en diferentes partes de su aplicación.

Con la inyección de dependencia, en lugar de crear una instancia de GroupMembershipService dentro de su PersonService , puede pasarlo al constructor PersonService , o bien agregar una propiedad (getter y setter) para establecer una instancia local de este. Esto significa que su PersonService ya no tiene que preocuparse por cómo crear un GroupMembershipService , solo acepta los que se le brindan y trabaja con ellos. Esto también significa que cualquier cosa que sea una subclase de GroupMembershipService , o implemente la interfaz de GroupMembershipService , puede ser "inyectada" en el PersonService , y el PersonService no necesita saber sobre el cambio.


La respuesta aceptada es buena, pero me gustaría agregar a esto que DI es muy similar a la clásica de evitar constantes codificadas en el código.

Cuando usas una constante como el nombre de una base de datos, la mueves rápidamente desde el interior del código a un archivo de configuración y pasas una variable que contiene ese valor al lugar donde se necesita. La razón para hacerlo es que estas constantes generalmente cambian con más frecuencia que el resto del código. Por ejemplo, si desea probar el código en una base de datos de prueba.

DI es similar a esto en el mundo de la programación orientada a objetos. Los valores en lugar de los literales constantes son objetos completos, pero la razón para mover el código que los crea a partir del código de clase es similar: los objetos cambian con más frecuencia que el código que los usa. Un caso importante donde se necesita tal cambio son las pruebas.


Probemos un ejemplo simple con las clases de Automóvil y Motor , cualquier automóvil necesita un motor para ir a cualquier parte, al menos por ahora. Así que debajo de cómo se verá el código sin inyección de dependencia.

public class Car
{
    public Car()
    {
        GasEngine engine = new GasEngine();
        engine.Start();
    }
}

public class GasEngine
{
    public void Start()
    {
        Console.WriteLine("I use gas as my fuel!");
    }
}

Y para crear una instancia de la clase Car usaremos el siguiente código:

Car car = new Car();

El problema con este código es que estamos estrechamente relacionados con GasEngine y si decidimos cambiarlo a ElectricityEngine, tendremos que volver a escribir la clase de automóvil. Y cuanto más grande sea la aplicación, más problemas y dolores de cabeza tendremos que agregar y usar un nuevo tipo de motor.

En otras palabras, con este enfoque es que nuestra clase de Automóviles de alto nivel depende de la clase de GasEngine de nivel inferior que viola el Principio de Inversión de Dependencia (DIP) de SOLID. DIP sugiere que deberíamos depender de abstracciones, no de clases concretas. Para satisfacer esto, introducimos la interfaz de IEngine y reescribimos el código como se muestra a continuación:

    public interface IEngine
    {
        void Start();
    }

    public class GasEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I use gas as my fuel!");
        }
    }

    public class ElectricityEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I am electrocar");
        }
    }

    public class Car
    {
        private readonly IEngine _engine;
        public Car(IEngine engine)
        {
            _engine = engine;
        }

        public void Run()
        {
            _engine.Start();
        }
    }

Ahora nuestra clase Car depende solo de la interfaz de IEngine, no de una implementación específica del motor. Ahora, el único truco es cómo creamos una instancia del Coche y le damos una clase de motor concreta real como GasEngine o ElectricityEngine. Ahí es donde entra la inyección de dependencia .

   Car gasCar = new Car(new GasEngine());
   gasCar.Run();
   Car electroCar = new Car(new ElectricityEngine());
   electroCar.Run();

Aquí básicamente inyectamos (pasamos) nuestra dependencia (instancia del motor) al constructor de coches. Así que ahora nuestras clases tienen un acoplamiento suelto entre los objetos y sus dependencias, y podemos agregar fácilmente nuevos tipos de motores sin cambiar la clase de Automóvil.

El principal beneficio de la inyección de dependencia es que las clases se acoplan de forma más flexible, ya que no tienen dependencias codificadas. Esto sigue el principio de inversión de dependencia, que se mencionó anteriormente. En lugar de hacer referencia a implementaciones específicas, las clases solicitan abstracciones (generalmente interfaces ) que se les proporcionan cuando se construye la clase.

Entonces, al final, la inyección de dependencia es solo una técnica para lograr un acoplamiento suelto entre los objetos y sus dependencias. En lugar de instanciar directamente las dependencias que la clase necesita para realizar sus acciones, las dependencias se proporcionan a la clase (la mayoría de las veces) a través de la inyección del constructor.

Además, cuando tenemos muchas dependencias, es una buena práctica utilizar contenedores de Inversión de Control (IOC) que nos permiten indicar qué interfaces deben asignarse a qué implementaciones concretas para todas nuestras dependencias y podemos hacer que las resuelva para nosotros cuando se construye. nuestro objeto Por ejemplo, podríamos especificar en la asignación para el contenedor IoC que la dependencia IEngine se debe asignar a la clase GasEngine y cuando le pedimos al contenedor IoC una instancia de nuestra clase Car , automáticamente construirá nuestra clase Car con una dependencia GasEngine aprobada en.

ACTUALIZACIÓN: He visto recientemente un curso sobre EF Core de Julie Lerman y también le gustó su breve definición sobre DI.

La inyección de dependencia es un patrón para permitir que su aplicación inyecte objetos sobre la marcha en las clases que los necesitan, sin obligar a esas clases a ser responsables de esos objetos. Permite que su código se acople más libremente, y Entity Framework Core se conecta a este mismo sistema de servicios.


Inyección de dependencia significa una forma (en realidad de cualquier manera ) para que una parte del código (por ejemplo, una clase) tenga acceso a las dependencias (otras partes del código, por ejemplo, otras clases, de las que depende) de manera modular sin que estén codificadas (así que pueden cambiarse o anularse libremente, o incluso cargarse en otro momento, según sea necesario)

(y ps, sí, se ha convertido en un nombre de $ 25 demasiado exagerado para un concepto bastante simple) , mis .25centavos


Encontré este ejemplo divertido en términos de acoplamiento suelto :

Cualquier aplicación se compone de muchos objetos que colaboran entre sí para realizar algunas cosas útiles. Tradicionalmente, cada objeto es responsable de obtener sus propias referencias a los objetos dependientes (dependencias) con los que colabora. Esto conduce a clases altamente acopladas y código difícil de probar.

Por ejemplo, considere un objeto de Car .

Un Car depende de las ruedas, el motor, el combustible, la batería, etc. para funcionar. Tradicionalmente, definimos la marca de dichos objetos dependientes junto con la definición del objeto Car .

Sin inyección de dependencia (DI):

class Car{
  private Wheel wh = new NepaliRubberWheel();
  private Battery bt = new ExcideBattery();

  //The rest
}

Aquí, el objeto Car es responsable de crear los objetos dependientes.

¿Qué NepaliRubberWheel() si queremos cambiar el tipo de su objeto dependiente, por ejemplo, Wheel , después de los pinchazos de NepaliRubberWheel() iniciales? Necesitamos recrear el objeto Car con su nueva dependencia, digamos ChineseRubberWheel() , pero solo el fabricante del Car puede hacerlo.

Entonces, ¿para qué nos sirve la Dependency Injection ...?

Cuando se usa la inyección de dependencia, los objetos reciben sus dependencias en tiempo de ejecución en lugar de tiempo de compilación (tiempo de fabricación del automóvil) . Así que ahora podemos cambiar la Wheel cuando queramos. Aquí, la dependency ( wheel ) se puede inyectar en el Car en el tiempo de ejecución.

Después de usar la inyección de dependencia:

Aquí, estamos inyectando las dependencias (Rueda y Batería) en tiempo de ejecución. De ahí el término: inyección de dependencia.

class Car{
  private Wheel wh = [Inject an Instance of Wheel (dependency of car) at runtime]
  private Battery bt = [Inject an Instance of Battery (dependency of car) at runtime]
  Car(Wheel wh,Battery bt) {
      this.wh = wh;
      this.bt = bt;
  }
  //Or we can have setters
  void setWheel(Wheel wh) {
      this.wh = wh;
  }
}

Fuente: Comprensión de la inyección de dependencia.


La inyección de dependencia es un tipo de implementación del principio de " Inversión de control " en el que se basa la creación de marcos.

Los marcos como se indica en el "Patrón de diseño" de GoF son clases que implementan la lógica de flujo de control principal, lo que hace que el desarrollador haga eso, de esta manera los marcos se dan cuenta de la inversión del principio de control.

Una forma de implementar como una técnica, y no como una jerarquía de clases, este principio de IoC es simplemente inyección de dependencia.

DI consiste principalmente en delegar la asignación de instancias de clases y la referencia de tipo a esas instancias, a una "entidad" externa: un objeto, una clase estática, un componente, un marco, etc.

Las instancias de clases son las " dependencias ", el enlace externo del componente que llama con la instancia de clase a través de la referencia es la " inyección ".

Obviamente, puede implementar esta técnica de la forma que desee desde el punto de vista de la POO, vea, por ejemplo , inyección de constructor , inyección de definidor , inyección de interfaz .

Delegar a un tercero para llevar a cabo la tarea de hacer coincidir una referencia con un objeto es muy útil cuando se desea separar completamente un componente que necesita algunos servicios de la misma implementación de servicios.

De esta manera, al diseñar componentes, puede concentrarse exclusivamente en su arquitectura y su lógica específica, confiando en las interfaces para colaborar con otros objetos sin preocuparse por ningún tipo de cambios de implementación de los objetos / servicios utilizados, también si el mismo objeto que está utilizando Será totalmente reemplazado (obviamente respetando la interfaz).


Todas las respuestas anteriores son buenas, mi objetivo es explicar el concepto de una manera sencilla para que cualquier persona sin conocimientos de programación también pueda entender el concepto.

La inyección de dependencia es uno de los patrones de diseño que nos ayudan a crear sistemas complejos de una manera más sencilla.

Podemos ver una gran variedad de aplicaciones de este patrón en nuestro día a día. Algunos de los ejemplos son grabadora de cinta, VCD, unidad de CD, etc.

La imagen de arriba es una imagen de una grabadora de cinta portátil de carrete a carrete, de mediados del siglo XX. Source .

La intención principal de una máquina grabadora de cinta es grabar o reproducir sonido. Mientras se diseña un sistema, se necesita un carrete para grabar o reproducir sonido o música. Podemos colocar el carrete dentro de la máquina o podemos proporcionar un gancho para el carrete donde se puede colocar. Si optamos por el segundo que coloca un gancho para el carrete, obtenemos un beneficio adicional de reproducir cualquier música cambiando el carrete y también reduciendo la función de reproducción de lo que sea en el carrete.

Los principales beneficios que conseguimos al utilizar la inyección de dependencia.

  • Alta cohesión y acoplamiento suelto.
  • Externalizando la dependencia y buscando solo la responsabilidad.
  • Haciendo cosas como componentes y combinándolos para formar un gran sistema con altas capacidades.
  • Ayuda a desarrollar componentes de alta calidad, ya que se desarrollan de forma independiente y se prueban adecuadamente.
  • Ayuda a reemplazar el componente con otro si uno falla.

Hoy en día, este concepto forma la base de marcos bien conocidos en el mundo de la programación. Los Spring Angular, etc. son los marcos de software conocidos que se basan en este concepto.

La inyección de dependencia es un patrón que se utiliza para crear instancias de objetos en los que otros objetos dependen sin saber en el momento de la compilación qué clase se usará para proporcionar esa funcionalidad o simplemente la forma de inyectar propiedades a un objeto se llama inyección de dependencia.

Ejemplo para inyección de dependencia

Anteriormente estamos escribiendo código como este.

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

Con la inyección de dependencia, el inyector de dependencia tomará la instanciación para nosotros

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 

  dependentObject.someMethod();
}

También puedes leer

Diferencia entre inversión de control e inyección de dependencia


La inyección de dependencia es el núcleo del concepto relacionado con Spring Framework. Mientras se crea el marco de cualquier proyecto, la primavera puede desempeñar un papel vital, y aquí la inyección de dependencia se presenta en el lanzador.

En realidad, supongamos que en java creaste dos clases diferentes como clase A y clase B, y cualquiera que sea la función disponible en la clase B que quieras usar en la clase A, entonces en ese momento se puede usar la inyección de dependencia. donde puede crear objetos de una clase en otra, de la misma manera que puede inyectar una clase completa en otra clase para hacerla accesible. De esta manera se puede superar la dependencia.

LA INYECCIÓN DE DEPENDENCIA ES SIMPLEMENTE ENCONTRAR DOS CLASES Y AL MISMO TIEMPO DE MANTENERLAS POR SEPARADO.



El objetivo principal de la inyección de dependencia (DI) es mantener el código fuente de la aplicación limpio y estable :

  • Limpio de código de inicialización de dependencia.
  • estable independientemente de la dependencia utilizada

Prácticamente, cada patrón de diseño separa las preocupaciones para que los cambios futuros afecten a los archivos mínimos.

El dominio específico de DI es la delegación de configuración de la dependencia y la inicialización.

Ejemplo: DI con shell script

Si ocasionalmente trabaja fuera de Java, recuerde cómo sourcese usa a menudo en muchos lenguajes de script (Shell, Tcl, etc., o incluso importen Python, mal usado para este propósito).

Considere un dependent.shscript simple :

#!/bin/sh
# Dependent
touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

El script es dependiente: no se ejecutará correctamente solo ( archive_filesno está definido).

Se define archive_filesen el archive_files_zip.shscript de implementación (utilizando zipen este caso):

#!/bin/sh
# Dependency
function archive_files {
    zip files.zip "[email protected]"
}

En lugar de sourceutilizar el script de implementación directamente en el dependiente, utiliza un injector.sh"contenedor" que envuelve ambos "componentes":

#!/bin/sh 
# Injector
source ./archive_files_zip.sh
source ./dependent.sh

La archive_files dependencia acaba de ser inyectada en el script dependiente .

Podrías haber inyectado la dependencia que implementa archive_filesusando taro xz.

Ejemplo: eliminar DI

Si el dependent.shscript usara las dependencias directamente, el enfoque se llamaría búsqueda de dependencia (que es opuesto a la inyección de dependencia ):

#!/bin/sh
# Dependent

# dependency look-up
source ./archive_files_zip.sh

touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

Ahora el problema es que el "componente" dependiente tiene que realizar la inicialización.

El código fuente del "componente" no es limpio ni estable porque cada cambio en la inicialización de las dependencias requiere una nueva versión para el archivo de código fuente de los "componentes"

Ultimas palabras

DI no se enfatiza ni se populariza tanto como en los marcos de Java.

Pero es un enfoque genérico para dividir las preocupaciones de:

  • desarrollo de aplicaciones ( ciclo de vida de lanzamiento de código fuente único )
  • despliegue de aplicaciones ( múltiples entornos de destino con ciclos de vida independientes)

El uso de la configuración solo con la búsqueda de dependencia no ayuda, ya que la cantidad de parámetros de configuración puede cambiar por dependencia (por ejemplo, el nuevo tipo de autenticación), así como la cantidad de tipos de dependencias compatibles (por ejemplo, el nuevo tipo de base de datos).


En palabras simples, la inyección de dependencia (DI) es la forma de eliminar las dependencias o el acoplamiento apretado entre diferentes objetos. La inyección de dependencia da un comportamiento cohesivo a cada objeto.

DI es la implementación del director de IOC de Spring que dice "No nos llames, te llamaremos". El uso del programador de inyección de dependencias no necesita crear un objeto con la nueva palabra clave.

Los objetos una vez se cargan en el contenedor de Spring y luego los reutilizamos cuando los necesitamos al buscarlos desde el contenedor de Spring utilizando el método getBean (String beanName).


La inyección de dependencia (DI) es parte de la práctica del Principio de inversión de dependencia (DIP), que también se denomina Inversión de control (IoC). Básicamente, necesita hacer DIP porque desea que su código sea más modular y comprobable por unidad, en lugar de un solo sistema monolítico. Entonces, comienza a identificar partes del código que pueden separarse de la clase y abstraerse. Ahora la implementación de la abstracción debe inyectarse desde fuera de la clase. Normalmente esto se puede hacer a través del constructor. Así que creas un constructor que acepta la abstracción como un parámetro, y esto se llama inyección de dependencia (a través del constructor). Para obtener más información sobre el contenedor DIP, DI e IoC, puede leer Here


La inyección de dependencia (DI) es una de los patrones de diseño, que utiliza la característica básica de la POO: la relación en un objeto con otro objeto. Mientras que la herencia hereda un objeto para hacer más complejo y específico otro objeto, la relación o asociación simplemente crea un puntero a otro objeto desde un objeto usando un atributo. El poder de DI está en combinación con otras características de OOP, como son las interfaces y el código de ocultación. Supongamos que tenemos un cliente (suscriptor) en la biblioteca, que solo puede pedir prestado un libro por simplicidad.

Interfaz de libro:

package com.deepam.hidden;

public interface BookInterface {

public BookInterface setHeight(int height);
public BookInterface setPages(int pages);   
public int getHeight();
public int getPages();  

public String toString();
}

A continuación podemos tener muchos tipos de libros; uno de tipo es la ficción:

package com.deepam.hidden;

public class FictionBook implements BookInterface {
int height = 0; // height in cm
int pages = 0; // number of pages

/** constructor */
public FictionBook() {
    // TODO Auto-generated constructor stub
}

@Override
public FictionBook setHeight(int height) {
  this.height = height;
  return this;
}

@Override
public FictionBook setPages(int pages) {
  this.pages = pages;
  return this;      
}

@Override
public int getHeight() {
    // TODO Auto-generated method stub
    return height;
}

@Override
public int getPages() {
    // TODO Auto-generated method stub
    return pages;
}

@Override
public String toString(){
    return ("height: " + height + ", " + "pages: " + pages);
}
}

Ahora el suscriptor puede tener asociación al libro:

package com.deepam.hidden;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

public class Subscriber {
BookInterface book;

/** constructor*/
public Subscriber() {
    // TODO Auto-generated constructor stub
}

// injection I
public void setBook(BookInterface book) {
    this.book = book;
}

// injection II
public BookInterface setBook(String bookName) {
    try {
        Class<?> cl = Class.forName(bookName);
        Constructor<?> constructor = cl.getConstructor(); // use it for parameters in constructor
        BookInterface book = (BookInterface) constructor.newInstance();
        //book = (BookInterface) Class.forName(bookName).newInstance();
    } catch (InstantiationException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    } catch (SecurityException e) {
        e.printStackTrace();
    } catch (IllegalArgumentException e) {
        e.printStackTrace();
    } catch (InvocationTargetException e) {
        e.printStackTrace();
    }
    return book;
}

public BookInterface getBook() {
  return book;
}

public static void main(String[] args) {

}

}

Las tres clases se pueden ocultar para su propia implementación. Ahora podemos usar este código para DI:

package com.deepam.implement;

import com.deepam.hidden.Subscriber;
import com.deepam.hidden.FictionBook;

public class CallHiddenImplBook {

public CallHiddenImplBook() {
    // TODO Auto-generated constructor stub
}

public void doIt() {
    Subscriber ab = new Subscriber();

    // injection I
    FictionBook bookI = new FictionBook();
    bookI.setHeight(30); // cm
    bookI.setPages(250);
    ab.setBook(bookI); // inject
    System.out.println("injection I " + ab.getBook().toString());

    // injection II
    FictionBook bookII = ((FictionBook) ab.setBook("com.deepam.hidden.FictionBook")).setHeight(5).setPages(108); // inject and set
    System.out.println("injection II " + ab.getBook().toString());      
}

public static void main(String[] args) {
    CallHiddenImplBook kh = new CallHiddenImplBook();
    kh.doIt();
}
}

Hay muchas maneras diferentes de cómo usar la inyección de dependencia. Es posible combinarlo con Singleton, etc., pero aún en básico solo se realiza asociación creando atributos de tipo de objeto dentro de otro objeto. La utilidad es única y única en función, ese código, que deberíamos escribir una y otra vez, siempre está preparado y hecho para nosotros. Esta es la razón por la que DI está tan estrechamente vinculada con la Inversión de Control (IoC), lo que significa que nuestro programa pasa a controlar otro módulo en ejecución, que inyecta beans a nuestro código. (Cada objeto, que se puede inyectar, se puede firmar o considerar como un Bean). Por ejemplo, en Spring se realiza creando e inicializando ApplicationContextcontenedor, que hace este trabajo para nosotros. Simplemente, en nuestro código creamos el contexto e invocamos la inicialización de los beans. En ese momento la inyección se ha realizado automáticamente.


La mejor analogía que se me ocurre es el cirujano y su asistente (s) en un quirófano, donde el cirujano es la persona principal y su asistente, que proporciona los diversos componentes quirúrgicos cuando los necesita para que el cirujano pueda concentrarse en el Lo que él hace mejor (cirugía). Sin el asistente, el cirujano tiene que obtener los componentes por sí mismo cada vez que necesita uno.

DI, para abreviar, es una técnica para eliminar una responsabilidad adicional común (carga) sobre los componentes para obtener los componentes dependientes, proporcionándolos.

DI te acerca al principio de responsabilidad única (SR), como el surgeon who can concentrate on surgery.

Cuándo usar DI: recomendaría usar DI en casi todos los proyectos de producción (pequeños / grandes), especialmente en entornos empresariales en constante cambio :)

Por qué: porque desea que su código sea fácilmente comprobable, simulable, etc. para que pueda probar rápidamente sus cambios y llevarlo al mercado. Además, ¿por qué no lo harías cuando hay un montón de herramientas / marcos gratuitos increíbles para ayudarte en tu viaje a una base de código donde tienes más control?


Las respuestas populares son inútiles, porque definen la inyección de dependencia de una manera que no es útil. Acordemos que por "dependencia" nos referimos a algún otro objeto preexistente que nuestro objeto X necesita. Pero no decimos que estamos haciendo "inyección de dependencia" cuando decimos

$foo = Foo->new($bar);

Simplemente llamamos a los parámetros que pasan al constructor. Lo hemos estado haciendo regularmente desde que se inventaron los constructores.

La "inyección de dependencia" se considera un tipo de "inversión de control", lo que significa que se saca algo de lógica de la persona que llama. Ese no es el caso cuando la persona que llama pasa los parámetros, por lo que si fuera DI, DI no implicaría una inversión de control.

DI significa que hay un nivel intermedio entre el llamante y el constructor que gestiona las dependencias. Un Makefile es un ejemplo simple de inyección de dependencia. El "llamador" es la persona que escribe "make bar" en la línea de comandos, y el "constructor" es el compilador. El Makefile especifica que la barra depende de foo, y hace un

gcc -c foo.cpp; gcc -c bar.cpp

antes de hacer un

gcc foo.o bar.o -o bar

La persona que escribe "make bar" no necesita saber que la barra depende de foo. La dependencia se inyectó entre "make bar" y gcc.

El propósito principal del nivel intermedio no es solo pasar las dependencias al constructor, sino listar todas las dependencias en un solo lugar y ocultarlas del codificador (no hacer que el codificador las proporcione).

Generalmente, el nivel intermedio proporciona fábricas para los objetos construidos, que deben proporcionar un rol que cada tipo de objeto solicitado debe cumplir. Esto se debe a que al tener un nivel intermedio que oculta los detalles de la construcción, ya incurrió en la penalización de extracción impuesta por las fábricas, por lo que también podría utilizar fábricas.


Sé que ya hay muchas respuestas, pero esto me resultó muy útil: http://tutorials.jenkov.com/dependency-injection/index.html

Sin dependencia:

public class MyDao {

  protected DataSource dataSource =
    new DataSourceImpl("driver", "url", "user", "password");

  //data access methods...
  public Person readPerson(int primaryKey) {...}

}

Dependencia:

public class MyDao {

  protected DataSource dataSource = null;

  public MyDao(String driver, String url, String user, String
 password){
    this.dataSource = new DataSourceImpl(driver, url, user, password);
  }

  //data access methods...
  public Person readPerson(int primaryKey)
  {...}

}

Observe cómo la DataSourceImplcreación de instancias se mueve a un constructor. El constructor toma cuatro parámetros que son los cuatro valores que necesita el DataSourceImpl. Aunque la MyDaoclase aún depende de estos cuatro valores, ya no satisface estas dependencias. Son proporcionados por cualquier clase creando una MyDaoinstancia.


Significa que los objetos solo deben tener tantas dependencias como sea necesario para hacer su trabajo y las dependencias deben ser pocas. Además, las dependencias de un objeto deben estar en interfaces y no en objetos "concretos", cuando sea posible. (Un objeto concreto es cualquier objeto creado con la palabra clave nueva). El acoplamiento suelto promueve una mayor reutilización, un mantenimiento más fácil y le permite proporcionar fácilmente objetos "simulados" en lugar de servicios costosos.

La "inyección de dependencia" (DI) también se conoce como "Inversión de control" (IoC), y se puede utilizar como una técnica para fomentar este acoplamiento suelto.

Hay dos enfoques principales para implementar DI:

  1. Inyección de constructor
  2. Inyección de Setter

Inyección de constructor

Es la técnica de pasar objetos dependientes a su constructor.

Tenga en cuenta que el constructor acepta una interfaz y no un objeto concreto. Además, tenga en cuenta que se lanza una excepción si el parámetro orderDao es nulo. Esto enfatiza la importancia de recibir una dependencia válida. La Inyección del constructor es, en mi opinión, el mecanismo preferido para dar a un objeto sus dependencias. Es claro para el desarrollador al invocar el objeto las dependencias que deben darse al objeto "Persona" para su correcta ejecución.

Inyección de Setter

Pero considere el siguiente ejemplo ... Suponga que tiene una clase con diez métodos que no tienen dependencias, pero está agregando un nuevo método que sí tiene una dependencia en IDAO. Puede cambiar el constructor para usar la Inyección de constructor, pero esto puede forzarle a realizar cambios en todas las llamadas de constructor en todo el lugar. Alternativamente, podría agregar un nuevo constructor que tome la dependencia, pero luego, ¿cómo puede un desarrollador saber cuándo usar un constructor sobre el otro? Finalmente, si la dependencia es muy costosa de crear, ¿por qué debería crearse y pasarse al constructor cuando solo se puede usar raramente? La "inyección de Setter" es otra técnica de DI que puede usarse en situaciones como esta.

La inyección de Setter no obliga a que las dependencias se pasen al constructor. En su lugar, las dependencias se establecen en propiedades públicas expuestas por el objeto que se necesita. Como se indicó anteriormente, los principales motivadores para hacer esto incluyen:

  1. Apoyar la inyección de dependencias sin tener que modificar el constructor de una clase heredada.
  2. Permitiendo que se creen recursos o servicios costosos lo más tarde posible y solo cuando sea necesario.

Este es el ejemplo de cómo se vería el código anterior:

public class Person {
    public Person() {}

    public IDAO Address {
        set { addressdao = value; }
        get {
            if (addressdao == null)
              throw new MemberAccessException("addressdao" +
                             " has not been initialized");
            return addressdao;
        }
    }

    public Address GetAddress() {
       // ... code that uses the addressdao object
       // to fetch address details from the datasource ...
    }

    // Should not be called directly;
    // use the public property instead
    private IDAO addressdao;






terminology