<dany98dev />
Torna al Blog
Pubblicato il 27 maggio 2026•
Best PracticeSoftware DevelopmentDesign Patterns

Dependency Injection (DI)

Cos'è la Dependency Injection, perché è fondamentale per scrivere codice disaccoppiato e testabile, e come implementarla con o senza framework.

Il Problema dell'Accoppiamento Rigido (Tight Coupling)

Immagina di scrivere un'applicazione in cui una classe ServizioOrdini deve inviare un'email di conferma all'utente ogni volta che viene completato un acquisto. L'approccio più intuitivo per molti sviluppatori alle prime armi è questo:

// Esempio di codice fortemente accoppiato
class ServizioEmail {
  invia(a: string, messaggio: string) {
    // Logica per inviare l'email tramite server SMTP
  }
}

class ServizioOrdini {
  private servizioEmail: ServizioEmail;

  constructor() {
    // La classe crea DIRETTAMENTE la sua dipendenza
    this.servizioEmail = new ServizioEmail();
  }

  completaOrdine(ordineId: string, emailCliente: string) {
    // ... logica per salvare l'ordine ...
    this.servizioEmail.invia(emailCliente, "Il tuo ordine è stato completato!");
  }
}

Questo approccio, apparentemente innocuo, introduce un problema gravissimo noto come accoppiamento rigido (Tight Coupling).

Perché questa struttura è pericolosa?

  1. Impossibile da testare in isolamento: Se provi a scrivere un test unitario per ServizioOrdini, il test invierà realmente un'email tramite SMTP, rendendo il test lento, fragile e dipendente dalla rete. Non puoi facilmente sostituire ServizioEmail con un oggetto finto (Mock) per verificare solo la logica di completamento dell'ordine.
  2. Nessuna flessibilità: Se decidessi di passare dall'invio email SMTP a un servizio di terze parti come SendGrid o AWS SES, o se volessi inviare un SMS al posto di un'email, saresti costretto a modificare direttamente la classe ServizioOrdini.
  3. Violazione del Single Responsibility Principle (SRP): La classe ServizioOrdini non solo gestisce gli ordini, ma si preoccupa anche di come istanziare, configurare e gestire il ciclo di vita del servizio email.

Cos'è la Dependency Injection (DI)?

La Dependency Injection (Iniezione delle Dipendenze) è un pattern di progettazione software che risolve brillantemente questo problema. Invece di far creare o cercare a una classe le proprie dipendenze, le dipendenze le vengono fornite ("iniettate") dall'esterno, solitamente tramite il costruttore.

Riprendendo la metafora di Hollywood: "Non chiamarci, ti chiameremo noi". La classe non si preoccupa di trovare i suoi strumenti; dichiara semplicemente di cosa ha bisogno e aspetta che qualcuno glieli passi.

DIP vs DI vs IoC: Facciamo chiarezza

Spesso questi tre termini vengono confusi, ma rappresentano tre concetti distinti e complementari:

  • Dependency Inversion Principle (DIP): È un principio di progettazione (la "D" dei principi SOLID) che stabilisce che i moduli di alto livello non devono dipendere da moduli di basso livello, ma entrambi devono dipendere da astrazioni (interfacce).
  • Dependency Injection (DI): È la tecnica pratica (il pattern) utilizzata per fornire le dipendenze a una classe.
  • Inversion of Control (IoC): È il concetto più ampio in cui il flusso di controllo di un programma viene invertito rispetto alla programmazione procedurale tradizionale (es. un framework che chiama il tuo codice, anziché il tuo codice che chiama una libreria).

Come Implementare la Dependency Injection

Riscriviamo l'esempio precedente applicando la Dependency Injection e rispettando il principio di inversione della dipendenza.

1. Definiamo un'astrazione (Interfaccia)

Creiamo un'interfaccia che definisce il contratto per qualsiasi servizio di notifica:

interface ServizioNotifiche {
  inviaNotifica(destinatario: string, messaggio: string): void;
}

2. Creiamo le implementazioni concrete

Possiamo ora creare diverse implementazioni che rispettano lo stesso contratto:

class ServizioEmailSMTP implements ServizioNotifiche {
  inviaNotifica(destinatario: string, messaggio: string) {
    console.log(`Email SMTP inviata a ${destinatario}: ${messaggio}`);
  }
}

class ServizioEmailSendGrid implements ServizioNotifiche {
  inviaNotifica(destinatario: string, messaggio: string) {
    console.log(`Email SendGrid inviata a ${destinatario}: ${messaggio}`);
  }
}

3. Applichiamo la Constructor Injection

Modifichiamo la classe ServizioOrdini affinché accetti l'astrazione tramite il costruttore:

class ServizioOrdini {
  // La classe dipende dall'astrazione (interfaccia), non da una classe concreta
  constructor(private servizioNotifiche: ServizioNotifiche) {}

  completaOrdine(ordineId: string, emailCliente: string) {
    // ... logica per salvare l'ordine ...
    this.servizioNotifiche.inviaNotifica(emailCliente, "Il tuo ordine è stato completato!");
  }
}

4. Iniettiamo la dipendenza a runtime

Quando creiamo l'applicazione reale, decidiamo quale implementazione passare:

// In produzione utilizziamo SendGrid
const servizioNotifiche = new ServizioEmailSendGrid();
const servizioOrdini = new ServizioOrdini(servizioNotifiche);

servizioOrdini.completaOrdine("123", "cliente@email.com");

Le Tipologie di Dependency Injection

Esistono tre modi principali per iniettare le dipendenze in una classe:

  1. Constructor Injection (Iniezione tramite Costruttore): Le dipendenze vengono passate come parametri del costruttore. È il metodo più comune ed estremamente raccomandato, poiché garantisce che l'oggetto non possa essere creato in uno stato non valido (senza le sue dipendenze essenziali).
  2. Property/Setter Injection (Iniezione tramite Setter): Le dipendenze vengono passate tramite metodi setter pubblici o proprietà pubbliche dopo che l'oggetto è stato creato. È utile per dipendenze opzionali o che possono cambiare a runtime, ma rende l'oggetto parzialmente configurabile e potenzialmente instabile se utilizzato prima dell'iniezione.
  3. Method/Parameter Injection (Iniezione tramite Parametro): La dipendenza viene passata direttamente come parametro del singolo metodo che ne ha bisogno, anziché all'intera classe. Ottimo se solo un metodo specifico richiede quella dipendenza e non si vuole appesantire lo stato dell'oggetto.

I Vantaggi Straordinari della Dependency Injection

  • Testabilità Perfetta: Nei tuoi unit test, puoi creare un oggetto "finto" (Mock) che implementa l'interfaccia ServizioNotifiche senza fare reali chiamate di rete, e iniettarlo nel costruttore di ServizioOrdini. Questo ti consente di testare la logica del servizio ordini in isolamento in pochissimi millisecondi.
  • Flessibilità e Manutenibilità: Se domani vuoi aggiungere l'invio di notifiche via SMS, ti basterà creare una classe ServizioSMS che implementa ServizioNotifiche e passarla nel costruttore di ServizioOrdini, senza modificare una singola riga di codice all'interno di quest'ultima classe (rispettando in pieno l'Open/Closed Principle dei SOLID).
  • Separazione delle Responsabilità (Separation of Concerns): La classe focalizza il 100% della sua attenzione sul suo reale scopo di business, delegando la creazione e la configurazione degli strumenti a un orchestratore esterno.

Servono per forza i Framework (IoC Containers)?

Assolutamente no! La Dependency Injection eseguita manualmente a mano (come abbiamo fatto negli esempi sopra) viene definita Pure DI o Manual DI. Per applicazioni di piccole e medie dimensioni, la Pure DI è eccellente, trasparente e priva di overhead tecnologico.

Tuttavia, in applicazioni enterprise di grandi dimensioni con centinaia di classi e catene di dipendenze complesse (ad esempio, la classe A dipende da B, che dipende da C, che dipende da D), la Pure DI può portare alla scrittura di un file di configurazione (Composition Root) gigantesco e noioso da mantenere.

In questi scenari, i framework di IoC Container (come NestJS in ambito Node/TypeScript, Spring in Java o l'IoC nativo di .NET Core) automatizzano il processo. Questi strumenti analizzano i costruttori delle classi e, tramite meccanismi di reflection, risolvono e iniettano automaticamente l'intera catena di dipendenze a runtime, lasciandoti libero di concentrarti solo sulla scrittura della logica di business.

Conclusione

La Dependency Injection non è una tecnologia o un framework, ma una best practice architetturale fondamentale. Rende il tuo codice disaccoppiato, incredibilmente facile da testare e pronto ad evolversi nel tempo senza costringerti a dolorosi refactoring.

Se unita a principi cardine come il Dependency Inversion Principle e a una strutturazione a livelli come la Clean Architecture, la DI rappresenta la chiave di volta per costruire software moderno, solido e flessibile.

Condividi questo articolo