Vraag Wat is Inversion of Control?


Inversion of Control (of IoC) kan behoorlijk verwarrend zijn wanneer het voor het eerst wordt aangetroffen.

  1. Wat is het?
  2. Welke problemen lost het op?
  3. Wanneer is het passend en wanneer niet?

1426
2017-08-06 03:35


oorsprong


antwoorden:


De patronen Inversion of Control (IoC) en Dependency Injection (DI) hebben allemaal betrekking op het verwijderen van afhankelijkheden uit uw code.

Stel dat uw toepassing een teksteditoronderdeel heeft en u spellingcontrole wilt bieden. Uw standaardcode ziet er ongeveer zo uit:

public class TextEditor {

    private SpellChecker checker;

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

Wat we hier hebben gedaan, creëert een afhankelijkheid tussen de TextEditor en de SpellChecker. In een IoC-scenario doen we in plaats daarvan iets als dit:

public class TextEditor {

    private IocSpellChecker checker;

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

In het eerste codevoorbeeld maken we een instantiatie SpellChecker (this.checker = new SpellChecker();), wat betekent dat de TextEditor klasse is direct afhankelijk van de SpellChecker klasse.

In het tweede codevoorbeeld creëren we een abstractie door de SpellChecker afhankelijkheidsklasse in TextEditor constructorsignatuur (initialisatie van afhankelijkheid in de klas niet). Dit stelt ons in staat om de afhankelijkheid te bellen en het vervolgens door te geven aan de TextEditor-klasse, zoals:

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

Nu maakt de client het TextEditor klasse heeft de controle over welke SpellChecker implementatie te gebruiken omdat we de afhankelijkheid injecteren in de TextEditor handtekening.

Dit is slechts een eenvoudig voorbeeld, er is een goede reeks artikelen door Simone Busoli die het in meer detail uitlegt.


1137
2017-08-06 07:22



Inversion of Control is wat u krijgt als uw programma callbacks, bijv. zoals een gui-programma.

In een oud schoolmenu hebt u bijvoorbeeld mogelijk:

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

daarbij de stroom van gebruikersinteractie besturen.

In een GUI-programma of zoiets, in plaats daarvan zeggen we

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

Dus nu wordt de besturing omgekeerd ... in plaats van dat de computer gebruikersinvoer in een vaste volgorde accepteert, bestuurt de gebruiker de volgorde waarin de gegevens worden ingevoerd en wanneer de gegevens in de database worden opgeslagen.

Kortom, alles met een gebeurteniskring, callbacks of execute triggers valt in deze categorie.


495
2017-08-06 05:42



Wat is Inversion of Control?

Als u deze eenvoudige twee stappen volgt, heeft u de controle omgekeerd:

  1. Scheiden wat- om een ​​deel van te doen wanneer-Toen doen.
  2. Verzekeren dat wanneer deel kent als weinig zo mogelijk over wat een deel; en vice versa.

Er zijn verschillende technieken mogelijk voor elk van deze stappen op basis van de technologie / taal die u gebruikt voor uw implementatie.

-

De inversie een deel van de Inversion of Control (IoC) is het verwarrende ding; omdat inversie is de relatieve term. De beste manier om IoC te begrijpen is dat woord te vergeten!

-

Voorbeelden

  • Evenementafhandeling. Event Handlers (what-to-do part) - Raising Events (when-to-do part)
  • Interfaces. Component-client (when-to-do-part) - Component Interface-implementatie (what-to-do-gedeelte)
  • xUnit fixure. Setup en TearDown (what-to-do-part) - xUnit frameworks roept Setup op aan het begin en TearDown aan het einde (when-to-do-gedeelte)
  • Sjabloon methode ontwerp patroon. template-methode when-to-do-onderdeel - primitief implementatie-onderdeel van de subklasse
  • DLL-containermethoden in COM. DllMain, DllCanUnload, etc (what-to-do part) - COM / OS (when-to-do part)

359
2017-07-22 17:34



Inversion of Controls gaat over het scheiden van zorgen.

Zonder IoC: Je hebt een laptop computer en je breekt per ongeluk het scherm. En stop, je vindt hetzelfde model laptopscherm nergens op de markt. Dus je zit vast.

Met IoC: Je hebt een desktop computer en je breekt per ongeluk het scherm. Je merkt dat je bijna elke desktopmonitor uit de markt kunt halen, en het werkt goed met je desktop.

Uw desktop implementeert IoC in dit geval met succes. Het accepteert een verscheidenheid van monitoren, terwijl de laptop dat niet doet, het heeft een specifiek scherm nodig om gerepareerd te worden.


89
2017-09-25 14:24



Inversion of Control (of IoC) gaat over vrijheid krijgen (Je gaat trouwen, je bent de vrijheid kwijt en je wordt gecontroleerd, je bent gescheiden, je hebt zojuist Inversion of Control geïmplementeerd, dat is wat we 'ontkoppeld' noemden. Een goed computersysteem ontmoedigt een zeer hechte relatie.) meer flexibiliteit (De keuken in uw kantoor serveert alleen schoon leidingwater, dat is uw enige keuze wanneer u wilt drinken. Uw baas heeft Inversion of Control geïmplementeerd door een nieuw koffiezetapparaat op te zetten, zodat u nu de flexibiliteit hebt om ofwel leidingwater of koffie te kiezen. ) en minder afhankelijkheid (Je partner heeft een baan, je hebt geen baan, je bent financieel afhankelijk van je partner, dus je wordt gecontroleerd.) Je vindt een baan, je hebt Inversion of Control geïmplementeerd. Een goed computersysteem stimuleert in-afhankelijkheid.)

Wanneer u een desktopcomputer gebruikt, hebt u slaven (of zeg gecontroleerd). Je moet voor een scherm zitten en ernaar kijken. Gebruik het toetsenbord om te typen en gebruik de muis om te navigeren. En een slecht geschreven software kan je nog meer verslaan. Als je je desktop vervangt door een laptop, dan heb je ietwat omgekeerde controle. Je kunt het gemakkelijk meenemen en verplaatsen. Dus nu kun je bepalen waar je bent met je computer, in plaats van dat je computer deze bestuurt.

Door Inversion of Control te implementeren krijgt een software- / objectconsument meer besturingselementen / opties over de software / objecten, in plaats van te worden beheerd of met minder opties.

Met de bovenstaande ideeën in gedachten. We missen nog steeds een belangrijk onderdeel van IoC. In het scenario van IoC is de software / object-consument een geavanceerd framework. Dat betekent dat de code die je hebt gemaakt niet door jezelf wordt opgeroepen. Laten we nu uitleggen waarom deze manier beter werkt voor een webtoepassing.

Stel dat uw code een groep werknemers is. Ze moeten een auto bouwen. Deze werknemers hebben een plaats en tools (een softwarematig raamwerk) nodig om de auto te bouwen. EEN traditioneel softwarematig raamwerk zal lijken op een garage met veel gereedschap. Dus de arbeiders moeten zelf een plan maken en de gereedschappen gebruiken om de auto te bouwen. Een auto bouwen is geen eenvoudige zaak, het zal voor de werknemers erg moeilijk zijn om goed te plannen en samen te werken. EEN modern software framework zal zijn als een moderne autofabriek met alle faciliteiten en managers op hun plaats. De werknemers hoeven geen plan te maken, de managers (onderdeel van het raamwerk, ze zijn de slimste mensen en hebben het meest geavanceerde plan gemaakt) zullen helpen coördineren, zodat de werknemers weten wanneer ze hun werk moeten doen (kader noemt je code). De werknemers moeten voldoende flexibel zijn om de hulpmiddelen te gebruiken die de managers hen geven (door Dependency Injection te gebruiken).

Hoewel de werknemers de controle over het beheer van het project op het hoogste niveau aan de managers (het kader) geven. Maar het is goed om sommige professionals te helpen. Dit is het concept van IoC waar het echt vandaan komt.

Moderne webtoepassingen met een MVC-architectuur zijn afhankelijk van het framework om URL-routering uit te voeren en controllers op hun plaats te zetten om het framework te laten callen.

Dependency Injection en Inversion of Control zijn gerelateerd. Afhankelijkheid Injectie is in de micro level en Inversion of Control is in de macro niveau. Je moet elke hap eten (implementeer DI) om een ​​maaltijd af te maken (IoC implementeren).


80
2018-03-04 19:33



Voordat u Inversion of Control gebruikt, moet u zich goed bewust zijn van het feit dat het zijn voor- en nadelen heeft en dat u moet weten waarom u het gebruikt als u dit doet.

Voors:

  • Uw code wordt ontkoppeld, zodat u gemakkelijk implementaties van een interface kunt uitwisselen met alternatieve implementaties
  • Het is een sterke motivator voor codering tegen interfaces in plaats van implementaties
  • Het is heel eenvoudig om eenheidstests te schrijven voor uw code, omdat deze niets anders te maken heeft dan de objecten die het in zijn constructor / setters accepteert en u ze eenvoudig kunt initialiseren met de juiste objecten afzonderlijk.

nadelen:

  • IoC keert niet alleen de besturingsstroom in uw programma om, het schakelt ook aanzienlijk uit. Dit betekent dat u niet langer alleen uw code kunt lezen en van de ene plaats naar de andere kunt gaan omdat de verbindingen die normaal in uw code voorkomen, niet meer in de code voorkomen. In plaats daarvan bevindt het zich in XML-configuratiebestanden of -annotaties en in de code van uw IoC-container die deze metagegevens interpreteert.
  • Er ontstaat een nieuwe klasse bugs waarbij je je XML-config of je annotaties verkeerd krijgt en je veel tijd kunt besteden aan het ontdekken waarom je IoC-container onder bepaalde voorwaarden een nulreferentie in een van je objecten injecteert.

Persoonlijk zie ik de sterke kanten van IoC en ik vind ze echt leuk, maar ik vermijd IoC waar mogelijk omdat het je software verandert in een verzameling klassen die niet langer een "echt" programma vormen maar gewoon iets dat door elkaar moet worden samengesteld. XML-configuratie of annotatiemetagegevens en zonder elkaar vallen (en vallen).


73
2018-02-12 14:31



  1. Wikipedia-artikel. Voor mij draait inversie van controle je sequentieel geschreven code om en verandert het in een delegatiestructuur. In plaats van dat je programma alles expliciet bestuurt, stelt je programma een klasse of bibliotheek in met bepaalde functies die moeten worden opgeroepen als bepaalde dingen gebeuren.

  2. Het lost codeduplicatie op. Vroeger zou u bijvoorbeeld handmatig uw eigen event-lus schrijven, de systeembibliotheken peilen naar nieuwe gebeurtenissen. Tegenwoordig vertel je de meeste moderne API's eenvoudigweg aan de systeembibliotheken in welke evenementen je geïnteresseerd bent, en het laat je weten wanneer ze zich voordoen.

  3. Inversie van controle is een praktische manier om codeduplicatie te verminderen, en als u merkt dat u een hele methode kopieert en slechts een klein deel van de code wijzigt, kunt u overwegen deze aan te pakken met omkering van de controle. Inversie van controle wordt in veel talen gemakkelijk gemaakt door het concept van afgevaardigden, interfaces of zelfs onbewerkte functie-aanwijzers.

    Het is niet aangewezen om in alle gevallen te gebruiken, omdat de stroom van een programma moeilijker te volgen is wanneer het op deze manier wordt geschreven. Het is een handige manier om methoden te ontwerpen bij het schrijven van een bibliotheek die zal worden hergebruikt, maar het moet spaarzaam worden gebruikt in de kern van je eigen programma, tenzij het echt een probleem van codeduplicatie oplost.


55
2017-08-06 04:33