Cos'è l'Dependency Injection e l'Inversion of Control?

Question

Accepted Answer

**Dependency Injection (DI)** significa che un oggetto riceve le sue dipendenze dall'esterno invece di crearle da solo. È una forma di **Inversion of Control (IoC)**: la responsabilità di collegare gli oggetti è *invertita* e passa dall'oggetto a un chiamante o a un contenitore.

## Senza DI vs. con DI

```python
# WITHOUT DI — the class controls its own dependencies (tight coupling)
class OrderService:
    def __init__(self):
        self.repo = PostgresOrderRepo()   # hard-wired; can't swap or test

# WITH DI — dependencies are passed in (loose coupling)
class OrderService:
    def __init__(self, repo: OrderRepo):  # any OrderRepo implementation
        self.repo = repo

# wiring happens outside:
service = OrderService(PostgresOrderRepo())   # prod
test    = OrderService(InMemoryOrderRepo())   # test — no DB needed
```

La classe ora dipende dall'*astrazione* `OrderRepo`, e qualcun altro decide quale implementazione concreta fornire.

## Forme di iniezione

| Forma | Come |
|---|---|
| Constructor | Passate al costruttore (preferito — dipendenze richieste esplicite) |
| Setter | Impostate tramite un metodo dopo la costruzione (dipendenze opzionali) |
| Interface/container | Un framework risolve e inietta (Spring, .NET DI) |

## Compromessi

```text
✓ Testable (inject fakes/mocks)   ✓ Swappable implementations
✓ Explicit dependencies            ⚠️ More wiring; indirection can obscure flow
⚠️ DI containers add "magic" → harder to trace what's wired where
```

## Perché è importante

DI è la realizzazione pratica del Dependency Inversion Principle — la logica di alto livello smette di dipendere da classi concrete e di basso livello.

Il vantaggio è la testabilità e la flessibilità: puoi sostituire un database finto nei test oppure scambiare un provider di pagamento in produzione modificando il wiring, non la logica di business.

Forma	Come
Constructor	Passate al costruttore (preferito — dipendenze richieste esplicite)
Setter	Impostate tramite un metodo dopo la costruzione (dipendenze opzionali)
Interface/container	Un framework risolve e inietta (Spring, .NET DI)