Risposta.

Principio di Inversione delle Dipendenze (DIP) — è un principio architettonico secondo cui:

• I moduli di alto livello non dovrebbero dipendere dai moduli di basso livello. Entrambi i tipi dovrebbero dipendere da astrazioni (interfacce).
• Le astrazioni non dovrebbero dipendere dai dettagli, i dettagli dovrebbero dipendere dalle astrazioni.

Ciò significa che la logica aziendale (ad esempio, un servizio per la gestione degli ordini) non dovrebbe conoscere e utilizzare direttamente l'implementazione concreta dell'infrastruttura (ad esempio, una classe che implementa l'invio di email), ma lavorare tramite un'astrazione (interfaccia), che viene iniettata attraverso un meccanismo di contenitore DI o manualmente.

Esempio di codice in C#:

public interface IEmailSender {
    void Send(string to, string message);
}

public class SmtpEmailSender : IEmailSender {
    public void Send(string to, string message) {
        // Implementazione dell'invio di email
    }
}

public class OrderService {
    private readonly IEmailSender _emailSender;

    public OrderService(IEmailSender emailSender) {
        _emailSender = emailSender;
    }
    public void PlaceOrder(string customer) {
        // logica aziendale
        _emailSender.Send(customer, "Il tuo ordine è stato effettuato!");
    }
}

Caratteristiche principali:

• Permette di sostituire facilmente i dettagli di implementazione (ad esempio, iniettare un mock nei test).
• Aumenta la testabilità e l'estensibilità dell'architettura.
• Garantisce una bassa accoppiamento dei moduli.

Domande ingannevoli.

DIP è semplicemente iniezione di dipendenze attraverso il costruttore?

No. DIP riguarda la separazione delle astrazioni dalle implementazioni. L'iniezione di dipendenze (Dependency Injection, DI) è solo uno strumento attraverso il quale si realizza il DIP. Il DIP può essere realizzato anche senza un contenitore DI, garantendo manualmente la separazione delle astrazioni e dei dettagli.

Se hai un'unica implementazione dell'interfaccia, il DIP è obbligatorio?

Sì, il principio è comunque applicabile se è possibile l'estensione. L'introduzione di astrazioni prepara il sistema a eventuali modifiche nei requisiti senza modificare il codice di alto livello. Anche con un'unica implementazione dell'interfaccia, la bassa accoppiamento facilita il testing e lo sviluppo del sistema.

È possibile violare il DIP utilizzando logica nelle fabbriche o nei service locator?

Sì. Se una fabbrica o un service locator conosce i dettagli di implementazione e li collega dinamicamente senza utilizzare un'interfaccia dal lato del cliente, il DIP viene violato, nonostante la presenza esterna di astrazioni.