PRINCIPLES

D - Dependency Inversion Principle

Dipendi da astrazioni, non da implementazioni concrete. I moduli di alto livello non devono dipendere da quelli di basso livello.

Il Problema

Dipendenze dirette da classi concrete creano accoppiamento forte. Difficile testare, sostituire implementazioni o estendere.

La Soluzione

Entrambi i livelli dipendono da astrazioni (interfacce). Iniettare dipendenze invece di crearle internamente.

Struttura

Interfacce/contratti al centro. Implementazioni concrete iniettate dall'esterno (Dependency Injection).

Partecipanti:
Astrazione - interfaccia/contratto
Implementazioni concrete - iniettate
Client - dipende solo dall'astrazione
Esempi di Codice

PROBLEMA: Violazione DIP

UserService dipende da MySQL direttamente. Impossibile testare o cambiare DB.

JAVASCRIPT
Loading...

SOLUZIONE: Dependency Inversion (DIP)

UserService dipende da astrazione. Database iniettato. Testabile e flessibile.

JAVASCRIPT
Loading...
Esempi nel Mondo Reale
Dependency Injection (Spring, Angular, NestJS)
Repository pattern (interfaccia, impl varie)
Logger interfaces (Winston, Bunyan intercambiabili)
Payment gateways (interfaccia comune, provider diversi)
Quando Usarlo
Sempre per dipendenze esterne (DB, API, file)
Per testing isolato (mock dependencies)
Quando vuoi sostituire implementazioni
Quando NON Usarlo
Dipendenze da librerie standard stabili (Math, Date)
Pattern Correlati
Dependency InjectionFactoryAbstract Factory