Injection de Dépendances, Inversion de Contrôle et Contrats d'Interface

Le Changement de Contrôle

En programmation traditionnelle, une classe est responsable de la création de ses propres dépendances. Si un TaxCalculator a besoin d’un RateSource pour récupérer les taux de taxe, il pourrait instancier un RemoteRateSource directement dans son constructeur. Cela crée une dépendance rigide : le calculateur ne peut pas fonctionner sans cette implémentation spécifique, ce qui rend les tests unitaires impossibles sans une connexion réseau active.

L’Inversion de Contrôle (IoC) inverse cette relation. Au lieu que le TaxCalculator contrôle la création du RateSource, le contrôle est délégué à une entité externe (le conteneur IoC ou une classe de bootstrap manuelle). Le calculateur déclare simplement ce dont il a besoin, et l’environnement le lui fournit. L’Injection de Dépendances (DI) est le mécanisme spécifique utilisé pour réaliser l’IoC, le plus souvent via l’injection par constructeur.

Injection par Constructeur et Contrat

L’injection par constructeur garantit qu’un composant n’est jamais dans un état invalide. En exigeant les dépendances dès l’instanciation, le compilateur garantit que le TaxCalculator possède un RateSource avant que toute méthode ne soit appelée.

Pour rendre cela flexible, on utilise une interface. L’interface définit le contrat — l’ensemble des méthodes attendues par le calculateur — sans spécifier comment ces méthodes sont implémentées. Cela nous permet de substituer une implémentation de production par une implémentation de test sans modifier une seule ligne de code du calculateur.

Exemple Concret : Système de Calcul de Taxe

Imaginons un système où les taux de taxe sont récupérés via une API externe en production, mais doivent être fixes lors des tests pour garantir des résultats déterministes.

Le Contrat

public interface RateSource {
    double getRate(String regionCode);
}

Les Implémentations

// Implémentation Production : Appelle une API distante
public class RemoteRateSource implements RateSource {
    @Override
    public double getRate(String regionCode) {
        // Illustratif : utiliserait normalement un RestClient
        System.out.println("Récupération depuis l'API distante...");
        return 0.20;
    }
}

// Implémentation Test : Retourne une valeur fixe
public class FixedRateSource implements RateSource {
    @Override
    public double getRate(String regionCode) {
        return 0.15;
    }
}

Le Composant

public class TaxCalculator {
    private final RateSource rateSource;

    // Injection par constructeur
    public TaxCalculator(RateSource rateSource) {
        this.rateSource = rateSource;
    }

    public double calculateTax(double amount, String region) {
        return amount * rateSource.getRate(region);
    }
}

Trace d’Exécution

Scénario A : Bootstrap Production

1. RemoteRateSource remote = new RemoteRateSource();
2. TaxCalculator prodCalc = new TaxCalculator(remote);
3. prodCalc.calculateTax(100, "US") → appelle RemoteRateSource.getRate → retourne 20.0.

Scénario B : Bootstrap Test

1. FixedRateSource fixed = new FixedRateSource();
2. TaxCalculator testCalc = new TaxCalculator(fixed);
3. testCalc.calculateTax(100, "US") → appelle FixedRateSource.getRate → retourne 15.0.

Le Mythe du Découplage Total

Il existe une idée reçue selon laquelle les interfaces suppriment tout couplage. Si elles suppriment le couplage d’implémentation (le calculateur ne connaît pas RemoteRateSource), elles ne suppriment pas le couplage sémantique.

Le couplage sémantique survient lorsque l’appelant s’attend à ce que l’implémentation se comporte d’une certaine manière non spécifiée par la signature de la méthode. Par exemple, si le TaxCalculator suppose que getRate ne retournera jamais un nombre négatif ou répondra toujours en moins de 100ms, il reste couplé au comportement de l’implémentation. Si un DatabaseRateSource est introduit et lance une SQLException (enveloppée dans une RuntimeException), le calculateur peut planter malgré le respect technique du contrat d’interface. Les interfaces définissent le quoi, mais le comment (performance, gestion d’erreurs, effets de bord) impacte toujours l’appelant.

Exercice

Tâche : Vous avez un NotificationService qui dépend d’une interface MessageSender. Vous avez deux implémentations : SmsSender et EmailSender. Vous voulez créer un BulkNotifier capable de basculer entre ces envoyeurs selon un paramètre de configuration au démarrage.

1. Comment le BulkNotifier doit-il recevoir le MessageSender ?
2. Si SmsSender nécessite une clé API payante et EmailSender un serveur SMTP, où ces identifiants doivent-ils être gérés ?
3. Si SmsSender échoue silencieusement alors que EmailSender lance une exception en cas d’échec, le BulkNotifier est-il vraiment découplé de l’implémentation ?

Réponse :

1. Via l’injection par constructeur : public BulkNotifier(MessageSender sender) { ... }.
2. Les identifiants doivent être gérés à l’intérieur des classes d’implémentation spécifiques (ou passés à leurs constructeurs lors du bootstrap), et non dans le BulkNotifier.
3. Non. C’est du couplage sémantique. La logique de gestion d’erreurs du BulkNotifier se comportera différemment selon l’implémentation injectée, prouvant que le contrat d’interface seul n’élimine pas les dépendances comportementales.

Pour approfondir

• Spring Data JPA: Persisting Entities
• Java records