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

voix
1k

Inversion de contrôle (ou IoC) peut être assez déroutant quand il est d'abord rencontré.

  1. Qu'Est-ce que c'est?
  2. Quels problèmes faut-il résoudre?
  3. Quand faut-il et quand ne pas?
Créé 06/08/2008 à 04:35
source utilisateur
Dans d'autres langues...                            


32 réponses

voix
1k

L'inversion des modèles de contrôle (IoC) et injection de dépendance (DI) sont sur la suppression des dépendances de votre code.

Par exemple, supposons que votre application a un composant éditeur de texte et que vous voulez fournir la vérification orthographique. Votre code standard ressemblerait à quelque chose comme 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 SpellChecker. Dans un scénario IoC nous au lieu de faire quelque chose comme ceci:

public class TextEditor {

    private IocSpellChecker checker;

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

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

Dans le deuxième exemple de code que nous créons une abstraction en ayant la SpellCheckerclasse de dépendance à la TextEditorsignature du constructeur (pas initialiser la dépendance en classe). Cela nous permet d'appeler la dépendance passe ensuite à la classe TextEditor comme ceci:

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

Maintenant , le client la création de la TextEditorclasse a le contrôle sur lequel la SpellCheckermise en œuvre à utiliser parce que nous injectons la dépendance à la TextEditorsignature.

Ceci est juste un exemple simple, il y a une bonne série d'articles par Simone Busoli qu'il explique plus en détail.

Créé 06/08/2008 à 08:22
source utilisateur

voix
485

Le contrôle est inversion de ce que vous obtenez lorsque votre callbacks programme, par exemple, comme un programme de IUG.

Par exemple, dans un ancien menu école, vous pourriez avoir:

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

contrôlant ainsi l'écoulement de l'interaction de l'utilisateur.

Dans un programme d'interface graphique ou somesuch, au lieu que 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 de l'entrée utilisateur d'accepter l'ordinateur dans un ordre fixe, l'utilisateur contrôle l'ordre dans lequel les données sont saisies, et lorsque les données sont enregistrées dans la base de données.

En gros, quelque chose avec une boucle d'événement, callbacks ou exécuter des déclencheurs tombe dans cette catégorie.

Créé 06/08/2008 à 06:42
source utilisateur

voix
356

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

Si vous suivez ces deux étapes simples, vous avez fait l'inversion de contrôle:

  1. Séparé ce -À-faire partie de quand -À-faire partie.
  2. Assurez -vous que quand une partie sait aussi peu que possible sur ce cadre; et vice versa.

Il existe plusieurs techniques possibles pour chacune de ces étapes basées sur la technologie / langue que vous utilisez pour votre mise en œuvre.

-

L' inversion partie de l'inversion de contrôle (IoC) est la chose déroutante; parce que l' inversion est le terme relatif. La meilleure façon de comprendre IoC est d'oublier ce mot!

-

Exemples

  • Gestion des événements. Event Handlers (ce à faire partie) - Événements Raising (quand-à-faire partie)
  • Interfaces. client des composants (quand à faire partie) - Mise en œuvre Component Interface (ce à faire partie)
  • xUnit fixure. Configuration et tearDown (ce à faire partie) - cadres xUnit appels à l'installation au début et à la fin tearDown (quand à faire partie)
  • modèle de conception de procédé modèle. méthode de modèle lors à faire partie - la mise en œuvre de la sous-classe primitive ce à faire partie
  • méthodes de conteneurs DLL dans COM. DllMain, DllCanUnload, etc (ce à faire partie) - COM / OS (quand à faire une partie)
Créé 22/07/2010 à 18:34
source utilisateur

voix
81

Des contrôles est une inversion de séparer les préoccupations.

Sans IoC : Vous avez un ordinateur portable ordinateur et vous cassez accidentellement l'écran. Et zut, vous trouvez le même écran d'ordinateur portable modèle est nulle part sur le marché. Donc , vous êtes coincé.

Avec IoC : Vous avez un ordinateur de bureau ordinateur et vous cassez accidentellement l'écran. Vous trouvez que vous pouvez simplement saisir presque tous les écrans de bureau du marché, et il fonctionne bien avec votre bureau.

Votre bureau met en œuvre avec succès IoC dans ce cas. Il accepte un type de variété de moniteurs, tandis que l'ordinateur portable ne fonctionne pas, il a besoin d'un écran spécifique pour se fixe.

Créé 25/09/2013 à 15:24
source utilisateur

voix
77

Inversion de contrôle (ou IoC), est sur le point d' obtenir la liberté (vous mariez, vous avez perdu la liberté et vous êtes contrôlé. Vous divorcez, vous venez de mise en œuvre Inversion de contrôle. Voilà ce que nous avons appelé, « découplé ». Bon système informatique dissuade une relation très proche.) plus de flexibilité (la cuisine dans votre bureau sert uniquement de l' eau du robinet propre, qui est votre seul choix quand vous voulez boire. votre patron a mis en œuvre Inversion de contrôle par la mise en place d' une nouvelle machine à café. maintenant , vous obtenez le la flexibilité de choisir soit l' eau du robinet ou du café.) et moins de dépendance (votre partenaire a un emploi, vous ne disposez pas d' un emploi, vous dépendez financièrement de votre partenaire, si vous contrôliez. vous trouvez un emploi, vous avez mis en œuvre Inversion de contrôle. Bon système informatique encourage en dépendance.)

Lorsque vous utilisez un ordinateur de bureau, vous avez trimé (ou dire, contrôlée). Vous devez vous asseoir devant un écran et regardez. Utilisation du clavier pour saisir et utiliser la souris pour naviguer. Et pouvez-vous encore plus esclave logiciel mal écrit. Si vous remplacez votre ordinateur de bureau avec un ordinateur portable, vous un peu de contrôle inversée. Vous pouvez facilement prendre et se déplacer. Alors maintenant, vous pouvez contrôler où vous êtes avec votre ordinateur, au lieu de votre ordinateur le contrôle.

En mettant en œuvre l'inversion de contrôle, obtenir un consommateur logiciel / objet plus des contrôles / options sur les logiciels / objets, au lieu d'être contrôlé ou ayant moins d'options.

Avec les idées ci-dessus à l'esprit. Il nous manque encore un élément clé de IoC. Dans le scénario de IoC, est un cadre sophistiqué du consommateur logiciel / objet. Cela signifie que le code que vous avez créé n'est pas appelé par vous-même. Maintenant, nous allons expliquer pourquoi cette façon fonctionne mieux pour une application Web.

Supposons que votre code est un groupe de travailleurs. Ils ont besoin de construire une voiture. Ces travailleurs ont besoin d' un lieu et des outils (un cadre de logiciel) pour construire la voiture. Un traditionnel cadre de logiciel sera comme un garage avec de nombreux outils. Ainsi , les travailleurs doivent faire eux - mêmes un plan et utiliser les outils pour construire la voiture. Construire une voiture n'est pas une affaire facile, il sera très difficile pour les travailleurs de planifier et de coopérer correctement. Un moderne cadre de logiciel sera comme une usine moderne de tous les équipements et les gestionnaires en place. Les travailleurs ne doivent pas faire un plan, les gestionnaires (partie du cadre, ce sont les personnes les plus intelligentes et fait le plan le plus sophistiqué) coordonne afin que les travailleurs savent quand faire leur travail (cadre appelle votre code). Les travailleurs ont juste besoin d'être suffisamment souple pour utiliser tous les outils les gestionnaires à leur donner ( à l'aide d' injection de dépendance).

Bien que les travailleurs donnent le contrôle de la gestion du projet au niveau supérieur aux gestionnaires (le cadre). Mais il est bon d'avoir des professionnels aider. C'est vraiment venu le concept de IoC de.

Les applications Web modernes avec une architecture MVC dépend du cadre pour faire l'URL de routage et de mettre en place des contrôleurs pour le cadre d'appeler.

L' injection de dépendance et de contrôle sont inversion liés. L' injection de dépendance est au micro niveau et de contrôle est inversion au macro niveau. Vous devez manger chaque bouchée (mettre en œuvre DI) afin de terminer un repas (mettre en œuvre IoC).

Créé 04/03/2013 à 20:33
source utilisateur

voix
72

Avant d'utiliser l'inversion de contrôle, vous devez être bien conscient du fait qu'il a ses avantages et ses inconvénients et vous devriez savoir pourquoi vous l'utilisez si vous le faites.

Avantages:

  • Votre code est découplé de sorte que vous pouvez facilement échanger des implémentations d'une interface avec les implémentations alternatives
  • Il est un puissant facteur de motivation pour le codage contre les interfaces mises en œuvre au lieu de
  • Il est très facile d'écrire des tests unitaires pour votre code, car cela dépend de rien d'autre que les objets qu'il accepte dans son constructeur / setters et vous pouvez facilement les initialiser avec les bons objets dans l'isolement.

Les inconvénients:

  • IoC non seulement l'inverse flux de contrôle dans votre programme, il obscurcit aussi considérablement. Cela signifie que vous ne pouvez plus simplement lire votre code et sauter d'un endroit à l'autre parce que les connexions qui seraient normalement dans votre code ne sont pas dans le code plus. Au contraire, il est dans les fichiers de configuration XML ou des annotations et dans le code de votre conteneur IoC qui interprète ces métadonnées.
  • Il en résulte une nouvelle classe de bugs où vous obtenez votre configuration XML ou vos annotations mal et vous pouvez passer beaucoup de temps à trouver pourquoi votre conteneur IoC injecte une référence null dans un de vos objets sous certaines conditions.

Personnellement, je vois les points forts de IoC et je les aime vraiment, mais je tends à éviter IoC chaque fois que possible, car il transforme votre logiciel dans une collection de classes qui ne constituent plus un programme « réel », mais juste quelque chose qui doit être mis en place par configuration XML ou les métadonnées d'annotation et tomberaient (et les chutes) en dehors sans elle.

Créé 12/02/2010 à 15:31
source utilisateur

voix
55
  1. Wikipedia Article . Pour moi, l' inversion de contrôle tourne votre code écrit de manière séquentielle et en le transformant en une structure de délégation. Au lieu de votre programme de commande explicitement tout, votre programme met en place une classe ou d'une bibliothèque avec certaines fonctions à appeler lorsque certaines choses se produisent.

  2. Il permet de résoudre la duplication de code. Par exemple, dans les vieux jours, vous écririez manuellement votre propre boucle d'événements, les sondages bibliothèques système pour les nouveaux événements. De nos jours, la plupart des API modernes vous disent tout simplement les bibliothèques système les événements qui vous intéressent, et il vous permettra de savoir quand ils se produisent.

  3. Inversion de contrôle est une façon pratique de réduire la duplication de code, et si vous vous trouvez la copie d'une méthode entière et en changeant seulement un petit morceau de code, vous pouvez envisager l'aborder avec l'inversion de contrôle. Est l'inversion de contrôle facile dans de nombreuses langues à travers le concept des délégués, des interfaces, ou même des pointeurs de fonction premières.

    Il ne convient pas d'utiliser dans tous les cas, car le flux d'un programme peut être plus difficile à suivre lors de l'écriture de cette façon. Il est un moyen utile pour concevoir des méthodes lors de l'écriture d'une bibliothèque qui sera réutilisée, mais il doit être utilisé avec parcimonie dans le cœur de votre propre programme à moins qu'il ne résout vraiment un problème de duplication de code.

Créé 06/08/2008 à 05:33
source utilisateur

voix
38

Mais je pense que vous devez être très prudent avec elle. Si vous abusez ce modèle, vous ferez la conception et le code encore plus compliqué très compliqué.

Comme dans cet exemple avec TextEditor: si vous avez un seul SpellChecker peut-être qu'il est pas vraiment nécessaire d'utiliser IoC? Sauf si vous avez besoin d'écrire des tests unitaires ou quelque chose ...

Quoi qu'il en soit: être raisonnable. Design pattern sont bonnes pratiques , mais pas la Bible à prêcher. Ne pas coller partout.

Créé 06/08/2008 à 23:08
source utilisateur

voix
34

Supposons que vous êtes un objet. Et vous allez dans un restaurant:

Sans IoC : vous demandez « pomme », et vous êtes toujours servi pomme quand vous demandez plus.

Avec IoC : Vous pouvez demander « fruit ». Vous pouvez obtenir différents fruits à chaque fois que vous obtenez servi. par exemple, pomme, orange, ou melon d'eau.

Alors, évidemment, IoC est préféré lorsque vous aimez les variétés.

Créé 25/09/2013 à 15:00
source utilisateur

voix
34

IoC / DI me pousse des dépendances aux objets d'appel. Super simple.

La réponse non techy est d'être capable d'échanger sur un moteur dans une voiture juste avant que vous l'allumez. Si tout se branche à droite (l'interface), vous êtes bon.

Créé 19/09/2008 à 03:54
source utilisateur

voix
23
  1. L'inversion de contrôle est un modèle utilisé pour des composants et des couches de découplage dans le système. Le motif est mis en oeuvre par l'injection de dépendances dans un composant quand il est construit. Ces dépendances sont généralement sous forme d'interfaces pour un découplage plus poussé et de soutenir testabilité. conteneurs IoC / DI, tels que le château de Windsor, l'unité sont des outils (bibliothèques) qui peuvent être utilisés pour fournir IoC. Ces outils offrent des fonctionnalités étendues au-delà de la simple gestion des dépendances, y compris la vie, AOP / interception, politique, etc.

  2. une. Soulage un composant d'être responsable de la gestion des dépendances est tout.
    b. Il offre la possibilité d'échanger des implémentations de dépendance dans des environnements différents.
    c. Permet à un composant testé par se moquant des dépendances.
    ré. Fournit un mécanisme de partage des ressources tout au long d' une application.

  3. une. Critical lorsque vous faites le développement piloté par les tests. Sans IoC il peut être difficile à tester, car les composants testés sont fortement couplés au reste du système.
    b. Critiques lors de l' élaboration des systèmes modulaires. Un système modulaire est un système dont les composants peuvent être remplacés sans nécessiter la recompilation.
    c. Critique s'il y a beaucoup de questions transversales qui doivent traiter, partilarly dans une application d'entreprise.

Créé 19/09/2008 à 03:27
source utilisateur

voix
17

Je vais écrire sur ma compréhension simple de ces deux termes:

For quick understanding just read examples*

Injection de dépendance (DI):
La dépendance des moyens d' injection généralement le passage d' un objet sur lequel la méthode dépend, en tant que paramètre à une méthode, au lieu d'avoir la méthode de créer l'objet dépendant .
Ce que cela signifie en pratique que la méthode ne dépend pas directement sur une mise en œuvre particulière; toute mise en œuvre qui répond aux exigences peut être passé en paramètre.

Avec ce objets dire thier dépendances. Et le printemps rend disponible.
Cela conduit au développement d'applications à couplage lâche.

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

Inversion of Control (IoC) Container:
Ceci est caractéristique commune des cadres, la COI gère les objets java
- de instanciation à la destruction par son BeanFactory.
-java composants qui sont instanciés par le conteneur IoC sont appelés grains, et le récipient CIO gère un champ d'application de haricot, des événements du cycle de vie, ainsi que les caractéristiques de AOP pour lequel il a été configuré et codés.

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it.

En mettant en œuvre l'inversion de contrôle, obtenir un consommateur logiciel / objet plus des contrôles / options sur les logiciels / objets, au lieu d'être contrôlé ou ayant moins d'options.

Inversion de contrôle comme guide de conception sert aux fins suivantes:

Il y a un découplage de l'exécution d'une tâche de mise en œuvre.
Chaque module peut se concentrer sur ce qu'il est conçu pour.
Les modules ne préjugent pas sur ce que les autres systèmes font , mais comptent sur leurs contrats.
Le remplacement des modules n'a aucun effet secondaire sur d' autres modules ,
je garderai des choses abstraites ici, vous pouvez visiter les liens suivants pour les détails compréhension du sujet.
Une bonne lecture avec l' exemple

Explication détaillée

Créé 10/11/2014 à 08:43
source utilisateur

voix
15

Par exemple, la tâche n ° 1 est de créer un objet. Sans notion du CIO, la tâche n ° 1 est censé être fait par Programmer.But Avec le concept du CIO, la tâche n ° 1 serait fait par conteneur.

En bref contrôle s'inverse du programmeur à conteneur. Ainsi, il est appelé comme l'inversion de contrôle.

J'ai trouvé un bon exemple ici .

Créé 27/01/2010 à 13:15
source utilisateur

voix
14

Répondre à seulement la première partie. Qu'Est-ce que c'est?

Inversion de contrôle (COI) des moyens pour créer des instances de dépendances première et dernière instance d'une classe (éventuellement en les injectant par le constructeur), au lieu de créer une instance de la première classe et l'instance de classe créant des instances de dépendances. Ainsi, l' inversion de contrôle intervertit le flux de contrôle du programme. Au lieu de la callee contrôler le flux de contrôle (tout en créant des dépendances), l' appelant contrôle le flux de contrôle du programme .

Créé 11/01/2016 à 00:49
source utilisateur

voix
14

Il semble que la chose la plus confus au sujet de « IoC » l'acronyme et le nom pour lequel il se trouve est qu'il est trop glamour d'un nom - presque un nom de bruit.

Avons-nous vraiment besoin d'un nom par lequel pour décrire la différence entre la programmation axée sur la procédure et l'événement? OK, si nous devons, mais avons-nous besoin de choisir un nouveau nom « plus grand que la vie » qui embrouille plus qu'elle ne résout?

Créé 19/01/2011 à 04:50
source utilisateur

voix
13

Laissez dire que nous faisons une réunion dans un hôtel.

Beaucoup de gens, beaucoup de carafes d'eau, de tasses en plastique.

Quand quelqu'un veut boire, elle remplir tasse, boisson et jeter tasse sur le sol.

Après une heure ou quelque chose que nous avons un plancher couvert de gobelets en plastique et de l'eau.

Laissez le contrôle inverse.

La même réunion au même endroit, mais au lieu de gobelets en plastique que nous avons un serveur avec une tasse en verre (Singleton)

et elle offre tout le temps aux clients de boire.

Quand quelqu'un veut boire, elle obtenir de verre garçon, boire et le retourner au serveur.

Laissant de côté la question de l'hygiène, la dernière forme de contrôle des processus de consommation est beaucoup plus efficace et économique.

Et c'est exactement ce que le printemps (un autre conteneur IoC, par exemple: Guice) fait. Au lieu de let à l'application de créer ce qu'il a besoin à l'aide nouveau mot-clé (en coupe en plastique), contenant Spring IoC tous offrent le temps de l'application de la même instance (singleton) de l'objet nécessaire (verre d'eau).

Pensez-vous comme organisateur de cette réunion. Vous avez besoin de la façon de contacter l'administration de l'hôtel qui

réunion des membres auront besoin verre d'eau, mais pas morceau de gâteau.

Exemple:-

public class MeetingMember {

    private GlassOfWater glassOfWater;

    ...

    public void setGlassOfWater(GlassOfWater glassOfWater){
        this.glassOfWater = glassOfWater;
    }
    //your glassOfWater object initialized and ready to use...
    //spring IoC  called setGlassOfWater method itself in order to
    //offer to meetingMember glassOfWater instance

}

Liens utiles:-

Créé 26/09/2012 à 18:54
source utilisateur

voix
13

Je suis d' accord avec NilObject , mais je voudrais ajouter ceci:

si vous vous trouvez la copie d'une méthode entière et en changeant seulement un petit morceau de code, vous pouvez envisager d'attaquer avec inversion de contrôle

Si vous vous copier et coller le code de trouver autour, vous faites presque toujours quelque chose de mal. Codifiées comme le principe de conception Une fois et une seule fois .

Créé 06/08/2008 à 06:20
source utilisateur

voix
10

IoC est sur l'inversion de la relation entre votre code et le code tiers (bibliothèque / cadre):

  • Dans s / w développement normal, vous écrivez la main () méthode et appeler les méthodes « bibliothèque ». Vous êtes dans le contrôle :)
  • Dans le IoC « cadre » contrôle principal () et appelle vos méthodes. Le cadre est en contrôle :(

DI (injection de dépendance) est sur la façon dont les flux de la commande dans l'application. (Méthode main ()) application de bureau traditionnel a généré des flux de contrôle de votre application à d'autres appels de méthode de la bibliothèque, mais avec le flux de contrôle DI est inversé qui est cadre prend soin de commencer votre application, initialisant et invoquer vos méthodes chaque fois que nécessaire.

À la fin vous gagnez toujours :)

Créé 19/09/2014 à 19:25
source utilisateur

voix
7

Inversion of Control est un principe générique, alors que l'injection de dépendances réalise ce principe en tant que modèle de conception pour la construction graphique de l'objet (à savoir les contrôles de configuration la façon dont les objets font référence à l'autre, plutôt que l'objet lui-même contrôler la façon d'obtenir la référence à un autre objet).

En regardant de contrôle comme Inversion un modèle de conception, nous devons examiner ce que nous inverseuses. L'injection de dépendance contrôle de la construction intervertit un graphe d'objets. Si dit au terme profane, l'inversion de contrôle implique un changement dans le contrôle de flux dans le programme. Par exemple. Dans l'application autonome traditionnelle, nous avons la méthode principale, d'où le contrôle est transmis à d'autres bibliothèques de tiers (dans le cas, nous avons utilisé la fonction de bibliothèque tierce partie), mais par l'inversion de contrôle de commande est transféré à partir du code de bibliothèque tierce partie à notre code , nous prenons le service de bibliothèque tierce partie. Mais il y a d'autres aspects qui doivent être inversées dans un programme - par exemple l'invocation des méthodes et des threads pour exécuter le code.

Pour ceux qui sont intéressés plus en profondeur sur l' inversion de contrôle un document a été publié décrivant une image plus complète de l' inversion de contrôle en tant que modèle de conception (OfficeFloor: en utilisant les modèles de bureau pour améliorer la conception de logiciels http://doi.acm.org/10.1145/ 2739011.2739013 avec un exemplaire gratuit disponible pour téléchargement à partir http://www.officefloor.net/mission.html )

Ce qui est identifié est la relation suivante:

Inversion de contrôle (pour les méthodes) = Dépendance (state) Injection Injection continue + + filetage Injection

Créé 29/10/2015 à 04:27
source utilisateur

voix
7

parlant de programmation

IoC en termes faciles: Il est l'utilisation de l'interface comme un moyen de quelque chose de spécifique (un tel champ ou un paramètre) comme caractère générique qui peut être utilisé par certaines classes. Il permet la réutilisation du code.

Par exemple, disons que nous avons deux classes: Chien et Chat . Les deux partagent les mêmes qualités / Etats: l' âge, la taille, le poids. Ainsi , au lieu de créer une classe de service appelé DogService et CatService , je peux créer un seul appelé AnimalService qui permet d'utiliser des chiens et chats seulement si elles utilisent l'interface IAnimal .

, Parlant pragmatiquement Cependant, il a une certaine arrière.

a) La plupart des développeurs ne savent pas comment l'utiliser . Par exemple, je peux créer une classe appelée Client et je peux créer automatiquement ( en utilisant les outils de l'IDE) une interface appelée Iaide . Donc, ce n'est pas rare de trouver un dossier rempli de classes et interfaces, peu importe si les interfaces seront réutilisées ou non. Il est appelé ballonnement. Certaines personnes pourraient faire valoir que « peut - être dans l'avenir , nous pourrions l' utiliser ». : - |

b) Il a des limiteurs. Par exemple, nous allons parler de l'affaire de chien et de chat et je veux ajouter un nouveau service (fonctionnalité) uniquement pour les chiens. Disons que je veux calculer le nombre de jours que je dois former un chien ( trainDays()), pour chat , il est inutile, les chats ne peuvent pas être formés (je plaisante).

b.1) Si j'ajoute trainDays()au service AnimalService il fonctionne aussi avec les chats et ce n'est pas valable.

b.2) Je peux ajouter une condition dans trainDays()laquelle il évalue dans quelle classe est utilisée. Mais il se brisera complètement le IoC.

b.3) Je peux créer une nouvelle classe de service appelé DogService juste pour les nouvelles fonctionnalités. Mais, il va augmenter la maintenabilité du code parce que nous aurons deux classes de service (avec des fonctionnalités similaires) pour chien et ce qui est mauvais.

Créé 19/04/2015 à 12:07
source utilisateur

voix
7

Vous trouverez une explication écrite très simple ici

http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

ça dit

« Toute demande non négligeable est composée de deux ou plusieurs classes qui collaborent entre eux pour effectuer une logique métier. Traditionnellement, chaque objet est chargé d'obtenir ses propres références aux objets qu'il collabore avec (ses dépendances). Lors de l'application DI, le les objets sont donnés leurs dépendances au moment de la création par une entité externe qui coordonne chaque objet dans le système. en d'autres termes, les dépendances sont injectées dans des objets « .

Créé 22/02/2013 à 15:13
source utilisateur

voix
6

J'aime cette explication: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Il commence simple et donne des exemples de code.

entrez la description d'image ici

Le consommateur, X, a besoin de la classe consommée, Y, pour accomplir quelque chose. C'est tout bon et naturel, mais ne X vraiment besoin de savoir qu'il utilise Y?

Est-il pas assez que X sait qu'il utilise quelque chose qui a le comportement, les méthodes, les propriétés etc, de Y, sans savoir qui met effectivement en œuvre le comportement?

En extrayant une définition abstraite du comportement utilisé par X dans Y, illustré ci-dessous comme je l'ai, et de laisser l'utiliser une instance X consommateur qu'au lieu de Y, il peut continuer à faire ce qu'il fait sans avoir à connaître les détails sur Y.

entrez la description d'image ici

Dans l'illustration ci-dessus Y implémente I et X utilise une instance de I. Bien qu'il soit tout à fait possible que X utilise encore Y ce qui est intéressant est X ne sait pas. Il sait juste qu'il utilise quelque chose qui implémente I.

Lire l'article pour plus d'informations et la description des avantages tels que:

  • X ne dépend pas de Y plus
  • Plus souple, la mise en œuvre peut être décidée dans l'exécution
  • L'isolement de l'unité de code, test plus facile

...

Créé 16/02/2017 à 02:03
source utilisateur

voix
4

L'inversion de contrôle est de transférer le contrôle à partir de la bibliothèque au client. Il est plus logique quand on parle d'un client qui injecte (passe) une valeur de fonction (expression lambda) dans une fonction d'ordre supérieur (fonction de bibliothèque) qui contrôle (changements) le comportement de la fonction de bibliothèque. Un client ou un cadre qui injecte des dépendances de la bibliothèque (qui portent comportement) dans les bibliothèques peuvent également être considérés comme IoC

Créé 24/12/2017 à 18:34
source utilisateur

voix
4

J'ai trouvé un exemple très clair ici qui explique comment le «contrôle est inversé.

Code classique (sans injection de dépendance)

Voici comment travailler à peu près un code de ne pas utiliser DI:

  • a besoin d'application Foo (par exemple un contrôleur), donc:
  • Application crée Foo
  • appelle l'application Foo
    • Foo Bar a besoin (par exemple un service), donc:
    • Foo Bar crée
    • Foo Bar appelle
      • Bar a besoin Bim (un service, d'un dépôt, ...), donc:
      • Bar crée Bim
      • Bar fait quelque chose

En utilisant l'injection de dépendance

Voici comment un code à l'aide DI à peu près travail:

  • a besoin d'application Foo, qui a besoin de Bar, qui a besoin Bim, donc:
  • Application crée Bim
  • Application crée Bar et donne Bim
  • Foo application crée et donne Bar
  • appelle l'application Foo
    • Foo Bar appelle
      • Bar fait quelque chose

Le contrôle des dépendances est inversée d'un être appelé à un appel.

Quels problèmes faut-il résoudre?

l'injection de dépendance, il est facile d'échanger avec les différentes mise en œuvre des classes injectées. Alors que les tests unitaires, vous pouvez injecter une mise en œuvre factice, ce qui rend le test beaucoup plus facile.

Ex: Supposons que votre application stocke le fichier téléchargé utilisateur dans le Google Drive, avec DI votre code de contrôleur peut ressembler à ceci:

class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

Lorsque vos besoins changent dire, au lieu de vous demander Google Drive à utiliser la boîte de transfert. Il vous suffit d'écrire une implémentation dropbox pour la StorageServiceInterface. Vous n'avez pas apporter des modifications dans le contrôleur tant que la mise en œuvre Dropbox adhère à la StorageServiceInterface.

Lors du test, vous pouvez créer la maquette pour la StorageServiceInterface avec la mise en œuvre fictive où toutes les méthodes renvoient null (ou toute valeur prédéfinie selon vos besoins de test).

Au lieu de cela , si vous aviez la classe de contrôleur pour construire l'objet de stockage avec le newmot - clé comme celui - ci:

class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

Lorsque vous voulez changer avec la mise en œuvre Dropbox vous devez remplacer toutes les lignes où l' newobjet GoogleDriveService est construit et utiliser les DropboxService. En plus lors du test de la classe SomeController le constructeur attend toujours la classe GoogleDriveService et les méthodes actuelles de cette classe sont déclenchées.

Quand faut - il et quand ne pas? À mon avis , vous utilisez DI quand vous pensez qu'il ya (ou il peut y avoir) implémentations alternatives d'une classe.

Créé 04/11/2017 à 13:27
source utilisateur

voix
4

Je comprends que la réponse a déjà été donnée ici. Mais je pense encore, quelques notions de base sur l'inversion de contrôle doivent être discutées ici en longueur pour les futurs lecteurs.

Inversion of Control (IoC) a été construit sur un principe très simple appelé Hollywood Principe . Et il est dit que,

Ne nous appelez pas, nous allons vous appeler

Ce que cela signifie est que ne vont pas à Hollywood pour réaliser votre rêve plutôt si vous êtes digne d'Hollywood alors vous trouver et faire de votre rêve se réalise. Quasiment inversé, hein?

Maintenant, quand nous discutons sur le principe de IoC, nous utilisons pour oublier Hollywood. Pour IoC, il doit y avoir trois éléments, un Hollywood, vous et une tâche comme pour réaliser votre rêve.

Dans notre monde de programmation, Hollywood représentent un cadre générique (peut être écrit par vous ou quelqu'un d' autre), vous représentez le code utilisateur que vous avez écrit et la tâche de représenter la chose que vous voulez accomplir avec votre code. Maintenant , vous n'allez jamais à déclencher votre tâche par vous - même, pas IoC! Plutôt que vous avez conçu tout ce que votre cadre déclenchera votre tâche pour vous. Ainsi , vous avez construit un cadre réutilisable qui peut rendre quelqu'un un héros ou un autre d' un méchant. Mais ce cadre est toujours responsable, il sait quand pour prendre quelqu'un et que quelqu'un ne sait ce qu'il veut être.

Un exemple concret de la vie serait donnée ici. Supposons que vous souhaitez développer une application web. Ainsi, vous créez un cadre qui se chargera de toutes les choses communes une application Web doit gérer comme le traitement des requêtes http, création menu de l'application, les pages de service, la gestion des cookies, le déclenchement d'événements, etc.

Et puis vous laissez quelques crochets dans votre cadre où vous pouvez mettre d'autres codes pour générer le menu personnalisé, les pages, les cookies ou vous connecter certains événements utilisateur, etc. A chaque demande de navigateur, votre cadre sera exécuté et exécute vos codes personnalisés si accroché puis servir de retour au navigateur.

Donc, l'idée est à peu près simple. Plutôt que de créer une application utilisateur qui contrôle tout, d'abord vous créer un cadre réutilisable qui contrôle tout alors écrire vos codes personnalisés et l'accrocher au cadre d'exécuter ceux dans le temps.

Laravel et EJB sont des exemples de tels cadres.

Référence:

https://martinfowler.com/bliki/InversionOfControl.html

https://en.wikipedia.org/wiki/Inversion_of_control

Créé 01/10/2017 à 11:24
source utilisateur

voix
4

IOC est également connu comme l'injection de dépendance (DI). Il est un processus par lequel les objets définissent leurs dépendances, à savoir les autres objets avec lesquels ils travaillent, que par arguments du constructeur, des arguments à une méthode de fabrication, ou des propriétés qui sont définies sur l'instance d'objet après qu'il est construit ou renvoyé par une méthode de fabrication . Le conteneur injecte alors ces dépendances quand il crée le haricot. Ce processus est fondamentalement l'inverse, d'où le nom inversion de contrôle (IOC), de la fève elle-même contrôler l'instanciation ou l'emplacement de ses dépendances en utilisant la construction directe de classes, ou un mécanisme tel que le motif Service de localisation

Page Printemps-cadre-referance.pfd 27 (si toutes les pages comptant de document pdf, il est à la page 51)

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/pdf/spring-framework-reference.pdf

Créé 24/01/2013 à 15:52
source utilisateur

voix
3

Inversion de contrôle est quand vous allez à l'épicerie et votre femme vous donne la liste des produits à acheter.

En termes de programmation , elle a adopté une fonction de rappel getProductList()à la fonction que vous exécutez doShopping();

Il permet à l'utilisateur de la fonction de définir certaines parties de celui-ci le rendant plus flexible.

Créé 15/12/2017 à 18:35
source utilisateur

voix
3

Pour comprendre le concept, l'inversion de contrôle (IoC) ou inversion des dépendances (DIP) comprend deux activités: l'abstraction et l'inversion. L'injection de dépendance (DI) est juste l'un des rares des méthodes d'inversion.

Pour en savoir plus sur ce que vous pouvez lire mon blog ici

  1. Qu'Est-ce que c'est?

Il est une pratique où vous laissez le comportement réel viennent de l'extérieur de la frontière (classe dans la programmation orientée objet). L'entité limite ne connaît que l'abstraction (par exemple interface, classe abstraite, délégué dans la programmation orientée objet) de celui-ci.

  1. Quels problèmes faut-il résoudre?

En terme de programmation, IoC essayer de résoudre le code monolithique en le rendant modulaire, découplage différentes parties de celui-ci, et en font unité testable.

  1. Quand faut-il et quand ne pas?

Il est approprié la plupart du temps, sauf si vous avez la situation où vous voulez juste le code monolithique (par exemple le programme très simple)

Créé 03/06/2016 à 01:46
source utilisateur

voix
3

Création d'un objet dans la classe est appelé couplage étroit, ressort supprime cette dépendance en suivant un modèle de conception (DI / COI). Dans quel objet de classe passé dans le constructeur plutôt que de créer en classe. Plus sur nous donnons grandeur de super classe dans le constructeur pour définir une structure plus générale.

Créé 13/05/2015 à 08:52
source utilisateur

voix
3
  1. Donc , le numéro 1 ci - dessus . Qu'est - ce que l' inversion de contrôle?

  2. L'entretien est la première chose qu'il résout pour moi. Il garantit que je utilise des interfaces de sorte que les deux classes ne sont pas intimes les uns avec les autres.

En utilisant un conteneur comme le château de Windsor, il résout les problèmes d'entretien encore mieux. Etre capable d'échanger un composant qui va à une base de données pour une qui utilise la persistance basée sur des fichiers sans changer une ligne de code est génial (changement de configuration, vous avez terminé).

Et une fois que vous entrez dans les médicaments génériques, il y a encore mieux. Imaginez avoir un éditeur de message qui reçoit des documents et publie des messages. Il ne se soucie pas ce qu'il publie, mais il a besoin d'un cartographe de prendre quelque chose d'un enregistrement à un message.

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

Je l'ai écrit une fois, mais maintenant je peux injecter beaucoup de types dans ce jeu de code si je publie différents types de messages. Je peux aussi écrire cartographes qui prennent un enregistrement du même type et les associer aux messages différents. En utilisant DI avec Generics m'a donné la possibilité d'écrire très peu de code pour accomplir de nombreuses tâches.

Oh oui, il y a des problèmes de testabilité, mais ils sont secondaires aux avantages de IoC / DI.

Je suis vraiment amoureuse IoC / DI.

3. Il devient plus approprié la minute où vous avez un projet de taille moyenne de complexité un peu plus. Je dirais qu'il est approprié de commencer la minute la sensation de douleur.

Créé 19/09/2008 à 05:59
source utilisateur

voix
2

L'utilisation IoC vous n'êtes pas new'ing vos objets. Votre conteneur IoC va faire et gérer la durée de vie d'entre eux.

Il résout le problème d'avoir à changer manuellement chaque instanciation d'un type d'objet à un autre.

Il est approprié lorsque vous avez des fonctionnalités qui peuvent changer à l'avenir ou qui peuvent varier en fonction de l'environnement ou la configuration utilisée dans.

Créé 16/07/2015 à 16:06
source utilisateur

voix
1

La première version de Java EE (J2EE à l'époque) a introduit le concept d'inversion de contrôle (IoC), ce qui signifie que le conteneur prendrait le contrôle de votre code d'entreprise et fournir des services techniques (tels que la transaction ou la gestion de la sécurité).

Créé 03/04/2017 à 22:42
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more