Sobes.tech
Middle

Quelle est la différence entre inversion de contrôle (IoC) et injection de dépendances ?

sobes.tech IA

Réponse de l'IA

L'inversion de contrôle (IoC) est un principe général de conception selon lequel le flux de contrôle d'un programme change : au lieu de gérer explicitement les dépendances et la logique de leur appel, le composant se fie à un framework ou un conteneur externe qui gère ce flux.

L'injection de dépendances (DI) est l'un des motifs spécifiques qui implémentent le principe IoC. Elle consiste à passer les dépendances (objets dont dépend le composant actuel) au composant depuis l'extérieur, au lieu que le composant les crée ou les recherche lui-même.

Ainsi, DI est une façon d'atteindre IoC.

Les principales différences :

  • IoC — principe/concept.
  • DI — motif/implémentation.
  • IoC peut être réalisé de différentes manières (par exemple, méthode de fabrique, localisateur de services), DI est l'une de ces méthodes.
  • IoC déplace la responsabilité de créer et de lier les objets de le composant vers le framework ou le conteneur.
  • DI réalise ce déplacement en passant les dépendances via le constructeur, le setter ou l'interface.

Exemple de DI (constructeur) :

// classe dépendante de Service
public class Client {
    private final Service service;

    // Le constructeur prend la dépendance (Service)
    public Client(Service service) {
        this.service = service;
    }

    public void doSomething() {
        service.execute();
    }
}

// Interface de dépendance
public interface Service {
    void execute();
}

// Implémentation concrète de la dépendance
public class ServiceImpl implements Service {
    @Override
    public void execute() {
        System.out.println("Exécution du service...");
    }
}

// Classe responsable de "l'injection"
public class AppConfig {
    public static void main(String[] args) {
        Service myService = new ServiceImpl(); // Création de la dépendance
        Client client = new Client(myService); // Injection de dépendance via le constructeur
        client.doSomething();
    }
}

Dans cet exemple, la classe Client ne crée pas directement ServiceImpl. Au lieu de cela, ServiceImpl est créé ailleurs (AppConfig) et passé (injecté) dans Client via son constructeur. Cela implémente le principe IoC, car la gestion de la création et de la liaison de Service est inversée : elle n'est pas dans Client.