Qu'est-ce que l'inversion de contrôle?

1827

L'inversion de contrôle (IoC) peut être assez déroutante lorsqu'elle est rencontrée pour la première fois.

Qu'Est-ce que c'est?
Quel problème résout-il?
Quand est-il approprié d'utiliser et quand non?

oop design-patterns inversion-of-control

— Mike Minutillo
source

292

Le problème avec la plupart de ces réponses est la terminologie utilisée. Qu'est-ce qu'un conteneur? Inversion? Dépendance? Expliquez-le en termes simples sans les grands mots.

— kirk.burleson

13

Voir aussi sur Programmers.SE: Pourquoi l'inversion du contrôle est-elle ainsi nommée?

— Izkata

8

C'est l'injection de dépendance (DI) - voir la description de Martin Fowlers ici: martinfowler.com/articles/injection.html#InversionOfControl

— Ricardo Sanchez

7

Cette photo résume un peu

— totymedli

C'est un adjectif, pas un nom, ce n'est pas une chose, c'est la description d'une modification apportée au code, où le contrôle du flux est dans le délégué, pas dans le conteneur.

— Martin Spamer

1524

Les modèles d'inversion de contrôle (IoC) et d'injection de dépendance (DI) visent à supprimer les dépendances de votre code.

Par exemple, supposons que votre application possède un composant éditeur de texte et que vous souhaitiez effectuer une vérification orthographique. Votre code standard ressemblerait à ceci:

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

Ce que nous avons fait ici crée une dépendance entre le TextEditoret le SpellChecker. Dans un scénario IoC, nous ferions plutôt quelque chose comme ceci:

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

Dans le premier exemple de code, nous instancions SpellChecker( this.checker = new SpellChecker();), ce qui signifie que la TextEditorclasse dépend directement de la SpellCheckerclasse.

Dans le deuxième exemple de code, nous créons une abstraction en ayant la SpellCheckerclasse de dépendance dans TextEditorla signature du constructeur de (pas en initialisant la dépendance dans la classe). Cela nous permet d'appeler la dépendance puis de la passer à la classe TextEditor comme ceci:

SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);

Maintenant, le client qui crée la TextEditorclasse a le contrôle sur l' SpellCheckerimplémentation à utiliser car nous injectons la dépendance dans la TextEditorsignature.

— urini
source

50

Bon exemple clair. Cependant, supposons qu'au lieu d'exiger que l'interface ISpellChecker soit transmise au constructeur de l'objet, nous l'avons exposée en tant que propriété réglable (ou méthode SetSpellChecker). Est-ce que cela constituerait toujours l'IoC?

— devios1

25

chainguy1337 - oui, ce serait le cas. L'utilisation de setters comme cela est appelée injection de setter par opposition à l'injection de constructeur (les deux techniques d'injection de dépendance). L'IoC est un modèle assez générique, mais l'injection de dépendances atteint l'IoC

— Jack Ukleja

257

Malgré les nombreux votes positifs, cette réponse est incorrecte. Veuillez consulter martinfowler.com/articles/injection.html#InversionOfControl . En particulier, notez la partie disant "Inversion de contrôle est un terme trop générique, et donc les gens le trouvent déroutant. En conséquence, avec beaucoup de discussions avec divers défenseurs de l'IoC, nous avons choisi le nom Dependency Injection".

— Rogério

45

Je suis d'accord avec @Rogeria. cela n'explique pas pourquoi on l'appelle l'IoC et je suis surpris par le nombre de votes positifs ;-)

— Aravind Yarram

31

Je me range du côté de @Rogerio et @Pangea. Cela peut être un bon exemple pour l' injection de constructeur mais pas une bonne réponse à la question d'origine. L'IoC, tel que défini par Fowler , peut être réalisé sans utiliser d'injection d'aucune sorte, par exemple en utilisant un localisateur de service ou même un simple héritage.

— mtsz

642

Inversion de contrôle est ce que vous obtenez lorsque votre programme rappelle, par exemple comme un programme GUI.

Par exemple, dans un menu old school, vous pourriez avoir:

print "enter your name"
read name
print "enter your address"
read address
etc...
store in database

contrôlant ainsi le flux d'interaction de l'utilisateur.

Dans un programme GUI ou un peu, au lieu de cela, nous disons:

when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase

Alors maintenant, le contrôle est inversé ... au lieu que l'ordinateur accepte les entrées de l'utilisateur dans un ordre fixe, l'utilisateur contrôle l'ordre dans lequel les données sont entrées et le moment où les données sont enregistrées dans la base de données.

Fondamentalement, tout ce qui a une boucle d'événements, des rappels ou des déclencheurs d'exécution tombe dans cette catégorie.

— Mark Harrison
source

161

ne marque pas ce type. techniquement, il a raison martinfowler.com/bliki/InversionOfControl.html IoC est un principe très général. Le flux de contrôle est «inversé» par l'injection de dépendances car vous avez effectivement délégué les dépendances à un système externe (par exemple, un conteneur IoC)

— Jack Ukleja

38

D'accord avec le commentaire de Schneider. 5 votes négatifs? L'esprit s'embrouille, car c'est la seule réponse qui est vraiment correcte. Notez l'ouverture: « comme un programme gui». L'injection de dépendance n'est que la réalisation la plus courante de l'IoC.

— Jeff Sternal

40

En effet, c'est l'une des rares réponses correctes ! Les gars, l'IoC n'est pas fondamentalement une question de dépendances. Pas du tout.

— Rogério

13

+1 - Ceci est une bonne description (avec un exemple) de la déclaration suivante de Martin Fowler - "Les premières interfaces utilisateur étaient contrôlées par le programme d'application. Vous auriez une séquence de commandes comme" Entrez le nom "," entrez l'adresse "; votre programme piloterait les invites et prendrait une réponse à chacune. Avec des interfaces graphiques (ou même basées sur l'écran), le cadre de l'interface utilisateur contiendrait cette boucle principale et votre programme fournissait à la place des gestionnaires d'événements pour les différents champs à l'écran. Le contrôle principal de le programme a été inversé, éloigné de vous vers le cadre. "

— Ashish Gupta

14

Je comprends maintenant pourquoi il est parfois appelé facétieusement le "Principe d'Hollywood: ne nous appelez pas, nous vous appellerons"