il modello di iniezione di dipendenza è sempre stato uno dei concetti che costano di capire nel mondo dello sviluppo del software, specialmente alle persone che stanno iniziando. Cos’è questo modello di design per qual è il tuo utilizzo? Normalmente quando programmiamo il giorno in giorno con la programmazione orientata agli oggetti lo troviamo costruire oggetti e relativi oggetti usando le dipendenze.
Ad esempio, possiamo avere un programma primario che utilizza un semplice servizio di stampa per stampare un documento.
package com.arquitecturajava;public class ServicioImpresion {public void imprimir() {System.out.println("enviando el documento a imprimir");System.out.println("imprimiendo el documento en formato pdf");}}
Utilizziamo un programma principale e Programma di programma:
package com.arquitecturajava;public class Principal {public static void main(String args) {ServicioImpresion miServicio= new ServicioImpresion();miServicio.imprimir();}}
Lass non ha niente di speciale e vedremo Il risultato stampato sulla console:
iniezione di dipendenza
Tuttavia la cosa logica è che questo programma divide un po ‘di più e questo composto di diversi servizi qualcosa come quanto segue:
finora tutto è abbastanza ragionevole e ciò che otteniamo è che il nostro servizio di stampa Dipende da altri servizi e responsabilità sono più chiari. Abbiamo appena generato dipendenze al servizio di stampa. Il codice sarebbe qualcosa come il seguente.
public class ServicioImpresion {ServicioEnvio servicioA;ServicioPDF servicioB; public ServicioImpresion() {this.servicioA= new ServicioEnvio();this.servicioB= new ServicioPDF();}public void imprimir() {servicioA.enviar();servicioB.pdf();}}
public class ServicioEnvio {public void enviar() {System.out.println("enviando el documento a imprimir");}}
public class ServicioPDF {public void pdf() {System.out.println("imprimiendo el documento en formato pdf");}}
Il risultato nella console sarà lo stesso solo che abbiamo diviso meglio.
La stessa operazione può essere eseguita iniettando le dipendenze al servizio di servizio e non è lui che deve definirli nel costruttore.
Sembra in Principio Un cambiamento non importante, il codice sarebbe:
package com.arquitecturajava.parte3;public class ServicioImpresion {ServicioEnvio servicioA;ServicioPDF servicioB;public ServicioImpresion(ServicioEnvio servicioA,ServicioPDF servicioB) {this.servicioA= servicioA;this.servicioB= servicioB;}public void imprimir() {servicioA.enviar();servicioB.pdf();}}
public class Principal {public static void main(String args) { ServicioImpresion miServicio= new ServicioImpresion(new ServicioEnvio(),new ServicioPDF());miServicio.imprimir();}}
Il risultato è lo stesso. Abbiamo appena iniettato le dipendenze del servizio dal nostro programma principale. Quali vantaggi questo contribuisce? . La realtà è che in linea di principio sembra che nessuno. Ma c’è qualcosa che è cambiato non è più il servizio stesso responsabile della definizione delle sue dipendenze, ma è il programma principale. Questo apre le porte all’estensibilità. Cioè, dobbiamo sempre iniettare le stesse dipendenze in servizio?. La risposta sembra ovvia … certo che sono già definiti. Tuttavia, la risposta è no, possiamo cambiare il tipo di dipendenza che iniettano, estendendo semplicemente una delle nostre classi e cambiare il comportamento, vediamo.
public class ServicioEnvioAspecto extends ServicioEnvio {@Overridepublic void enviar() {System.out.println("haciendo log del correo que vamos a enviar");super.enviar();}}
Abbiamo appena creato una classe che estende Serviceenvius e aggiunge una funzionalità di registro aggiuntiva che rende un “log” dell’e-mail che inviamo. Ora è semplice come dire il programma principale che quando si inietta la dipendenza non inietta il modulo Serviceenvi noi Avrà cambiato considerevolmente il comportamento.
public class Principal {public static void main(String args) {ServicioImpresion miServicio= new ServicioImpresion(new ServicioEnvioAspecto(),new ServicioPDF());miServicio.imprimir();}}
Il risultato nella console sarà:
Abbiamo appena modificato il comportamento del nostro programma in modo significativo grazie all’uso del concetto Iniezione di dipendenza
L’iniezione di dipendenza ci consente di iniettare altre classi e aggiungere funzionalità trasversali personalizzate. Questo modello di design è quello che apre la porta alle strutture come primavera usando il concetto di iniezione di dipendenza in modo più avanzato. In questi quadro, gli aspetti che vengono aggiunti alle nostre classi sono multiple e elevate complessità.
L’importanza del modello di iniezione di dipendenza è oggi nella maggior parte dei quadri.
altri articoli correlati
- Spring @qualifier usando @autowoxed
- Spring @import, organizzando quadro a molla
- java 8 pattern di fabbrica e la sua implementazione
elementi esterni
- Iniezione di dipendenza