Inyección de dependencias

Un servicio es cualquier clase que contiene funcionalidad útil. A su vez, un cliente es cualquier clase que utiliza servicios. Los servicios que un cliente requiere son las dependencias del cliente .

Cualquier objeto puede ser un servicio o un cliente; los nombres se refieren únicamente al rol que desempeñan los objetos en una inyección. Un mismo objeto puede incluso ser tanto un cliente (utiliza servicios inyectados) como un servicio (se inyecta en otros objetos). Tras la inyección, el servicio pasa a formar parte del estado del cliente y queda disponible para su uso. ^{[ 12 ]}

Los clientes no deberían conocer la implementación de sus dependencias, solo sus nombres y la API . Por ejemplo, un servicio que recupera correos electrónicos puede usar los protocolos IMAP o POP3 internamente, pero este detalle probablemente sea irrelevante para el código que simplemente busca recuperar un correo electrónico. Al ignorar los detalles de implementación, los clientes no necesitan modificar sus dependencias.

El inyector , a veces también llamado ensamblador, contenedor, proveedor o fábrica, introduce servicios al cliente.

La función de los inyectores es construir y conectar grafos de objetos complejos, donde los objetos pueden ser tanto clientes como servicios. El inyector en sí puede estar formado por muchos objetos que trabajan juntos, pero no debe ser el cliente, ya que esto crearía una dependencia circular .

Debido a que la inyección de dependencias separa la forma en que se construyen los objetos de la forma en que se utilizan, a menudo disminuye la importancia de la newpalabra clave presente en la mayoría de los lenguajes orientados a objetos . Dado que el framework se encarga de crear servicios, el programador tiende a construir directamente solo objetos de valor que representan entidades en el dominio del programa (como un Employeeobjeto en una aplicación empresarial o un Orderobjeto en una aplicación de compras). ^{[ 13 ] [ 14 ] [ 15 ] [ 16 ]}

A modo de analogía, podemos considerar los automóviles como servicios que realizan la útil labor de transportar personas de un lugar a otro. Los motores de los automóviles pueden requerir gasolina , diésel o electricidad , pero este detalle es irrelevante para el cliente —el pasajero— a quien solo le importa que el vehículo lo lleve a su destino.

Los automóviles presentan una interfaz uniforme a través de sus pedales, volantes y demás controles. Por lo tanto, el motor con el que fueron equipados en la fábrica deja de ser relevante, y los conductores pueden cambiar entre cualquier tipo de automóvil según sus necesidades.

Una ventaja básica de la inyección de dependencias es la disminución del acoplamiento entre las clases y sus dependencias. ^{[ 17 ] [ 18 ]}

Al eliminar el conocimiento del cliente sobre cómo se implementan sus dependencias, los programas se vuelven más reutilizables, comprobables y mantenibles. ^{[ 19 ]}

Esto también resulta en una mayor flexibilidad: un cliente puede actuar sobre cualquier cosa que admita la interfaz intrínseca que espera. ^{[ 20 ]}

En términos más generales, la inyección de dependencias reduce el código repetitivo , ya que toda la creación de dependencias es manejada por un único componente. ^{[ 19 ]}

Finalmente, la inyección de dependencias permite el desarrollo concurrente. Dos desarrolladores pueden desarrollar de forma independiente clases que se utilizan mutuamente, necesitando únicamente conocer la interfaz a través de la cual se comunicarán. Los complementos suelen ser desarrollados por terceros que ni siquiera se comunican con los desarrolladores del producto original. ^{[ 21 ]}

Los críticos de la inyección de dependencias argumentan que:

• Crea clientes que exigen detalles de configuración, lo cual puede ser oneroso cuando existen valores predeterminados obvios. ^{[ 21 ]}
• Hace que el código sea difícil de rastrear porque separa el comportamiento de la construcción. ^{[ 21 ]}
• Normalmente se implementa con reflexión o programación dinámica, lo que dificulta la automatización del IDE . ^{[ 24 ]}
• Por lo general, requiere un mayor esfuerzo de desarrollo inicial. ^{[ 25 ]}
• Fomenta la dependencia de un marco. ^{[ 26 ] [ 27 ] [ 28 ]}

En el siguiente ejemplo de Java , la Clientclase contiene una Servicevariable miembro inicializada en el constructor . El cliente construye y controla directamente qué servicio utiliza, creando una dependencia codificada.

clase pública Cliente { servicio privado servicio ;Cliente () { // La dependencia está codificada. this . service = new ExampleService (); } }

La forma más común de inyección de dependencias consiste en que una clase solicite sus dependencias a través de su constructor . Esto garantiza que el cliente siempre se encuentre en un estado válido, ya que no puede instanciarse sin las dependencias necesarias.

clase pública Cliente { servicio privado servicio ;// La dependencia se inyecta a través de un constructor. Cliente ( Servicio servicio ) { if ( servicio == null ) { throw new IllegalArgumentException ( "el servicio no debe ser nulo" ); } this . servicio = servicio ; } }

// una clase singleton concreta class DatabaseConnection { private static DatabaseConnection instance ;private DatabaseConnection () { // inicialización de recursos de la base de datos }public static synchronized DatabaseConnection instance () { if ( instance == null ) { instance = new DatabaseConnection (); } return instance ; }public void executeQuery ( String sql ) { System . out . printf ( "Ejecutando: %s%n" ); } }// una clase de consumidor estrechamente acoplada class OrderService { public void placeOrder ( String orderId ) { // la búsqueda de dependencia codificada hace que esto sea imposible de probar unitariamente DatabaseConnection db = DatabaseConnection . instance (); db . executeQuery ( String . format ( "INSERT INTO orders VALUES ('%s')" )); } }

// una interfaz abstracta interface Database { void executeQuery ( String sql ) ; }// Implementar la clase concreta (sin lógica singleton) class SqlDatabase implements Database { @Override public void executeQuery ( String sql ) { System . out . println ( "Ejecutando SQL: %s" , sql ); } }// La clase consumidora acepta la dependencia a través de la inyección del constructor. class OrderService { private final Database db ;// La dependencia se inyecta desde el exterior public OrderService ( Database db ) { this . db = db ; }public void placeOrder ( String orderId ) { db . executeQuery ( String . format ( "INSERT INTO orders VALUES ('%s')" , orderId )); } }

Las dependencias se pasan como argumentos a un método específico, lo que permite utilizarlas únicamente durante la ejecución de dicho método sin necesidad de mantener una referencia a largo plazo. Este enfoque resulta especialmente útil para dependencias temporales o cuando se requieren implementaciones diferentes para distintas llamadas a métodos.

public class Client { public void performAction ( Service service ) { if ( service == null ) { throw new IllegalArgumentException ( "service no debe ser nulo" ); } service . execute (); } }

Al aceptar las dependencias mediante un método setter , en lugar de un constructor, los clientes pueden permitir que los inyectores manipulen sus dependencias en cualquier momento. Esto ofrece flexibilidad, pero dificulta garantizar que todas las dependencias se inyecten y sean válidas antes de que se utilice el cliente.

clase pública Cliente { servicio privado servicio ;// La dependencia se inyecta a través de un método setter. public void setService ( Service service ) { if ( service == null ) { throw new IllegalArgumentException ( "service no debe ser nulo" ); } this . service = service ; } }

Con la inyección de interfaz, las dependencias desconocen por completo a sus clientes, pero aun así envían y reciben referencias a nuevos clientes.

De esta forma, las dependencias se convierten en inyectores. La clave reside en que el método de inyección se proporciona a través de una interfaz.

Aún se necesita un ensamblador para introducir el cliente y sus dependencias. El ensamblador toma una referencia al cliente, la convierte a la interfaz setter que establece esa dependencia y la pasa a ese objeto de dependencia, que a su vez pasa una referencia a sí mismo de vuelta al cliente.

Para que la inyección de interfaz tenga valor, la dependencia debe realizar alguna acción adicional además de simplemente devolver una referencia a sí misma. Esto podría consistir en actuar como una fábrica o subensamblador para resolver otras dependencias, abstraiendo así algunos detalles del ensamblador principal. También podría ser un sistema de conteo de referencias para que la dependencia sepa cuántos clientes la están utilizando. Si la dependencia mantiene una colección de clientes, podría posteriormente inyectarles a todos una instancia diferente de sí misma.

paquete org.wikipedia.examples ;importar java.util.HashSet ; importar java.util.Set ;interface ServiceSetter { void setService ( Service service ); }clase Cliente implementa ServiceSetter { private Service servicio ;@Override public void setService ( Service service ) { if ( service == null ) { throw new IllegalArgumentException ( "service no debe ser nulo" ); } this . service = service ; } }clase ServiceInjector { private final Set < ServiceSetter > clientes = new HashSet <> ();public void inject ( ServiceSetter client ) { this.clients.add ( client ) ; client.setService ( new ExampleService ( ) ) ; }​​public void switch () { for ( Client client : this . clients ) { client . setService ( new AnotherExampleService ()); } } }clase ExampleService implementa Service {}clase AnotherExampleService implementa Service {}

La inyección manual de dependencias suele ser tediosa y propensa a errores en proyectos grandes, lo que fomenta el uso de frameworks que automatizan el proceso. La inyección manual de dependencias se convierte en un framework de inyección de dependencias cuando el código de construcción deja de ser específico de la aplicación y se vuelve universal. ^{[ 32 ]} Si bien son útiles, estas herramientas no son necesarias para realizar la inyección de dependencias. ^{[ 33 ] [ 34 ]}

En Java, históricamente Java EE proporcionaba un marco de inyección de dependencias bajo javax.inject; ahora lo proporciona Jakarta EE como jakarta.inject, con la jakarta.inject.Provider<T>interfaz para obtener instancias de T, y las siguientes anotaciones : ^{[ 35 ]}

• @Inject, para marcar constructores, métodos y campos inyectables
• @Named, para marcar un calificador basado en cadena
• @Qualifier, para marcar anotaciones de calificadores
• @Scope, para marcar anotaciones de alcance
• @Singleton, para marcar un tipo sujeto al patrón singleton por el inyector

En .NET (como C# ), la Microsoft.Extensions.DependencyInjectionbiblioteca es un marco de trabajo incluido dentro de .NET. ^{[ 36 ]}

Algunos frameworks, como Spring , pueden utilizar archivos de configuración externos para planificar la composición del programa:

paquete org.wikipedia.examples ;import org.springframework.beans.factory.BeanFactory ; import org.springframework.context.ApplicationContext ; import org.springframework.context.support.ClassPathXmlApplicationContext ;public class Injector { public static void main ( String [] args ) { // Los detalles sobre qué servicio concreto usar se almacenan en la configuración separada del propio programa. BeanFactory beanfactory = new ClassPathXmlApplicationContext ( "Beans.xml" ); Client client = ( Client ) beanfactory . getBean ( "client" ); System . out . println ( client . greet ()); } }

Incluso con un grafo de objetos potencialmente largo y complejo, la única clase mencionada en el código es el punto de entrada, en este caso Client. Clientno ha sufrido ningún cambio para funcionar con Spring y sigue siendo un POJO . ^{[ 37 ] [ 38 ] [ 39 ]} Al evitar que las anotaciones y llamadas específicas de Spring se dispersen entre muchas clases, el sistema permanece solo débilmente dependiente de Spring. ^{[ 27 ]}

El siguiente ejemplo muestra un componente de Angular que recibe un servicio de saludo mediante inyección de dependencias:

/* greeter.service.ts */ import { Injectable , inject } from '@angular/core' ; import { DOCUMENT } from '@angular/common' ;export interface IGreeterService { greet ( text : string ) : void ; }@Injectable ({ providedIn : 'root' }) export class GreeterService implements IGreeterService { // Usa inject(DOCUMENT) y accede a defaultView para obtener el objeto Window private window : Window = inject ( DOCUMENT ). defaultView as Window ;saludar ( texto : cadena ) : void { this . window . alert ( texto ); } }

<!-- my-controller.component.html --> < div > < button ( click )=" sayHello ()" > Hola </ button > </ div >

/* my-controller.component.ts */ import { GreeterService } from './greeter.service.ts' ; import { Component , inject } from '@angular/core' ; @Component ({ selector : 'app-my-controller' , template : 'my-controller.component.html' }) export class MyControllerComponent {privado greeter = inyectar ( GreeterService );sayHello () : void { this.greeter.greet ( ' Hola Mundo ' ) ; } }

La injectfunción activa el inyector para crear una instancia del objeto GreeterServicey sus dependencias (en este caso, una Documentinstancia para acceder al windowobjeto).

Este ejemplo proporciona una muestra de inyección de constructor en C++ .

importar std ;clase DatabaseConnection { public : void connect () { std :: println ( "Conectando con la base de datos..." ); } };clase DatabaseService { private : DatabaseConnection & dbConn ; public : explicit DatabaseService ( DatabaseConnection & db ) : dbConn { db } {}void execute () { dbConn . connect (); std :: println ( "Ejecutando servicio de base de datos..." ); } };int main ( int argc , char * argv []) { DatabaseConnection db ; DatabaseService sv ( db ); sv.execute ( ) ; }

Este ejemplo proporciona una muestra de inyección de interfaz en C++.

importar std ;using std :: expected ; using std :: shared_ptr ; using std :: unexpected ;clase IConnection { public : enum class Error { NO_CONNECTION , // más errores aquí };virtual void connect () = 0 ; virtual ~ IConnection () = default ; };clase DatabaseConnection : public IConnection { public : DatabaseConnection () = default ;void connect () override { std :: println ( "Conectando con la base de datos..." ); } };clase DatabaseService { private : shared_ptr <IConnection> conn ; public : DatabaseService ( ) = default ;​void setConnection ( shared_ptr < IConnection > nextConn ) noexcept { conn = nextConn ; }expected < void , IConnection :: Error > execute () { if ( conn ) { conn -> connect (); std :: println ( "Ejecutando servicio de base de datos..." ); } else { return unexpected ( IConnection :: Error :: NO_CONNECTION ); } } };int main ( int argc , char * argv [ ] ) { shared_ptr <DatabaseConnection> db = std :: make_shared <DatabaseConnection> ( ) ; DatabaseService sv ; sv.setConnection ( db ) ; sv.execute ( ) ; }​

Este ejemplo proporciona una muestra de inyección de constructor en C# .

espacio de nombres Wikipedia.Ejemplos ;usando el sistema ;// Nuestro cliente solo conocerá esta interfaz, no qué mando específico está utilizando. interface IGamePadFunctionality { string GetGamePadName (); void SetVibrationPower ( float power ); }// Los siguientes servicios proporcionan implementaciones concretas de la interfaz anterior.clase XboxGamePad : IGamePadFunctionality { float vibrationPower = 1.0f ; public string GetGamePadName () => "Controlador Xbox" ; public void SetVibrationPower ( float power ) => this . vibrationPower = Math . Clamp ( power , 0.0f , 1.0f ); }clase PlayStationJoystick : IGamePadFunctionality { float vibratingPower = 100.0f ; public string GetGamePadName () => "Controlador de PlayStation" ; public void SetVibrationPower ( float power ) => this . vibratingPower = Math . Clamp ( power * 100.0f , 0.0f , 100.0f ); }clase SteamController : IGamePadFunctionality { double vibrating = 1.0 ; public string GetGamePadName () => "Controlador Steam" ; public void SetVibrationPower ( float power ) => this . vibrating = Convert . ToDouble ( Math . Clamp ( power , 0.0f , 1.0f )); }// Esta clase es el cliente que recibe un servicio. class GamePad { IGamePadFunctionality gamePadFunctionality ;// El servicio se inyecta a través del constructor y se almacena en el campo anterior. public GamePad ( IGamePadFunctionality gamePadFunctionality ) => this . gamePadFunctionality = gamePadFunctionality ;public void Showcase () { // Se utiliza el servicio inyectado. string gamePadName = this.gamePadFunctionality.GetGamePadName ( ); string message = $"Estamos usando el {gamePadName} ahora mismo, ¿ quieres cambiar la potencia de vibración ? " ; Console.WriteLine ( message ) ; } }class Program { static void Main ( string [] args ) { SteamController steamController = new (); // También podríamos haber pasado un XboxController, PlayStationJoystick, etc. // El mando no sabe qué está usando y no necesita saberlo. GamePad gamepad = new ( steamController ); gamepad . Showcase (); } }

Go no admite clases y, por lo general, la inyección de dependencias se abstrae mediante una biblioteca dedicada que utiliza reflexión o genéricos (estos últimos compatibles desde Go 1.18 ^{[ 40 ]} ). ^{[ 41 ]} Un ejemplo más sencillo sin utilizar bibliotecas de inyección de dependencias se ilustra con el siguiente ejemplo de una aplicación web MVC .

Primero, pasa las dependencias necesarias a un enrutador y luego del enrutador a los controladores:

enrutador de paquetesimport ( "database/sql" "net/http""ejemplo/controladores/usuarios""github.com/go-chi/chi/v5" "github.com/go-chi/chi/v5/middleware""github.com/redis/go-redis/v9" "github.com/rs/zerolog" )type RoutingHandler struct { // pasar los valores por puntero más abajo en la pila de llamadas // significa que no crearemos una nueva copia, ahorrando memoria log * zerolog . Logger db * sql . DB cache * redis . Client router chi . Router }// La conexión, el registrador y la caché se inicializan normalmente en la función principal func NewRouter ( log * zerolog . Logger , db * sql . DB , cache * redis . Client , ) ( r * RoutingHandler ) { rtr := chi . NewRouter ()return & RoutingHandler { log : log , db : db , cache : cache , router : rtr , } }func ( r * RoutingHandler ) SetupUsersRoutes () { uc := users . NewController ( r . log , r . db , r . cache )r . router . Get ( "/users/:name" , func ( w http . ResponseWriter , r * http . Request ) { uc . Get ( w , r ) }) }

De esta forma, se puede acceder a los campos privados de la estructura en cualquier método que sea su receptor de puntero , sin violar la encapsulación.

usuarios del paqueteimport ( "database/sql" "net/http""ejemplos/modelos""github.com/go-chi/chi/v5" "github.com/redis/go-redis/v9" "github.com/rs/zerolog" )tipo Controller struct { log * zerolog . Logger storage models . UserStorage cache * redis . Client }func NewController ( log * zerolog . Logger , db * sql . DB , cache * redis . Client ) * Controller { return & Controller { log : log , storage : models . NewUserStorage ( db ), cache : cache , } }func ( uc * Controller ) Get ( w http . ResponseWriter , r * http . Request ) { // tenga en cuenta que también podemos envolver el registro en un middleware, esto es para fines de demostración uc . log . Info (). Msg ( "Obteniendo usuario" )parámetro de usuario : = chi . URLParam ( r , "nombre" )var user * models . User // obtener el usuario de la caché err := uc . cache . Get ( r . Context (), userParam ). Scan ( & user ) if err != nil { uc . log . Error (). Err ( err ). Msg ( "Error al obtener el usuario de la caché. Recuperando del almacenamiento SQL" ) }usuario , err = uc.storage.Get ( r.Context ( ) , " johndoe" ) if err ! = nil { uc.log.Error ( ) . Err ( err ) .Msg ( " Error al obtener el usuario del almacenamiento SQL" ) http.Error ( w , " Error interno del servidor " , http.StatusInternalServerError ) return } }

Finalmente, la conexión a la base de datos inicializada en la función principal se puede utilizar en la capa de acceso a datos:

modelos de paquetesimport ( "database/sql" "time" )tipo ( UserStorage struct { conn * sql . DB }Estructura de usuario { Nombre cadena ' json : "nombre" db : "nombre,claveprimaria" ' UnidoEn tiempo . Tiempo ' json : "unido_en" db : "unido_en" ' Correo electrónico cadena ' json : "correo electrónico" db : "correo electrónico" ' } )func NewUserStorage ( conn * sql . DB ) * UserStorage { return & UserStorage { conn : conn , } }func ( us * UserStorage ) Get ( name string ) ( user * User , err error ) { // suponiendo que 'name' es una clave única query := "SELECT * FROM users WHERE name = $1"if err := us . conn . QueryRow ( query , name ). Scan ( & user ); err != nil { return nil , err }devolver usuario , nil }

En Rust , la inyección de dependencias se realiza normalmente a través de genéricos con despacho estático .

trait Logger { fn log ( & self , mensaje : & str ); }struct ConsoleLogger ;impl Logger para ConsoleLogger { fn log ( & self , message : & str ) { println! ( "{message}" ); } }struct UserService < L : Logger > { logger : L , }impl < L : Logger > UserService < L > { fn new ( logger : L ) -> Self { Self { logger } }fn create_user ( & self , name : & str ) { self . logger . log ( & format! ( "Creando usuario: {name}" )); // Lógica de negocio... } }fn main () { let logger = ConsoleLogger ; let service = UserService :: new ( logger );servicio.create_user ( "Alice " ) ; }

Sin embargo, también se puede hacer utilizando el despacho dinámico con objetos de rasgos:

trait Logger { fn log ( & self , mensaje : & str ); }struct ConsoleLogger ;impl Logger para ConsoleLogger { fn log ( & self , message : & str ) { println! ( "{message}" ); } }struct UserService { logger : Box < dyn Logger > , }impl UserService { fn new ( logger : Box < dyn Logger > ) -> Self { Self { logger } }fn create_user ( & self , name : & str ) { self . logger . log ( & format! ( "Creando usuario: {name}" )); } }fn main () { let logger = Box :: new ( ConsoleLogger ); let service = UserService :: new ( logger );servicio.create_user ( "Alice " ) ; }