Réponse.

Principe d'Inversion de Dépendance (DIP) — c'est un principe architectural selon lequel :

• Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux types doivent dépendre des abstractions (interfaces).
• Les abstractions ne doivent pas dépendre des détails, les détails doivent dépendre des abstractions.

Cela signifie que la logique métier (par exemple, le service de gestion des commandes) ne doit pas connaître et utiliser directement une implémentation concrète de l'infrastructure (par exemple, une classe qui implémente l'envoi d'emails), mais doit travailler à travers une abstraction (interface) qui est injectée via un conteneur DI ou manuellement.

Exemple de code en C# :

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

public class SmtpEmailSender : IEmailSender {
    public void Send(string to, string message) {
        // Implémentation de l'envoi d'email
    }
}

public class OrderService {
    private readonly IEmailSender _emailSender;

    public OrderService(IEmailSender emailSender) {
        _emailSender = emailSender;
    }
    public void PlaceOrder(string customer) {
        // logique métier
        _emailSender.Send(customer, "Votre commande a été passée !");
    }
}

Caractéristiques clés :

• Permet de remplacer facilement les détails d'implémentation (par exemple, injecter un mock lors des tests).
• Augmente la testabilité et l'extensibilité de l'architecture.
• Assure un faible couplage entre les modules.

Questions pièges.

Le DIP est-il juste une injection de dépendance via le constructeur ?

Non. Le DIP concerne la séparation des abstractions des implémentations. L'injection de dépendances (Dependency Injection, DI) n'est qu'un outil pour réaliser le DIP. Le DIP peut être mis en œuvre même sans conteneur DI, en assurant manuellement la séparation des abstractions et des détails.

Si vous avez une seule implémentation de l'interface, le DIP est-il nécessaire ?

Oui, le principe reste applicable même s'il est possible d'étendre. L'introduction d'abstractions prépare le système à la modification des exigences sans modification du code de haut niveau. Même avec une seule implémentation de l'interface, un faible couplage facilite le test et le développement du système.

Peut-on violer le DIP en utilisant la logique dans les usines ou les localisateurs de service ?

Oui. Si l'usine ou le localisateur de service connaît les détails d'implémentation et les lie dynamiquement sans utiliser d'interface du côté client, le DIP est violé, malgré la présence externe d'abstractions.