design-patterns - Wat is inversie van controle?

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

Wat is het?
Welk probleem lost het op?
Wanneer is het gepast om te gebruiken en wanneer niet?

Antwoord 1, autoriteit 100%

De patronen van Inversion of Control (IoC) en Dependency Injection (DI) hebben alles te maken met het verwijderen van afhankelijkheden uit uw code.

Stel bijvoorbeeld dat uw toepassing een teksteditorcomponent heeft en dat u spellingcontrole wilt uitvoeren. 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 TextEditoren de SpellChecker.
In een IoC-scenario zouden we in plaats daarvan zoiets als dit doen:

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

In het eerste codevoorbeeld instantiëren we SpellChecker(this.checker = new SpellChecker();), wat de klasse TextEditorbetekent hangt rechtstreeks af van de klasse SpellChecker.

In het tweede codevoorbeeld maken we een abstractie door de SpellChecker-afhankelijkheidsklasse in de constructorhandtekening van TextEditorte hebben (geen afhankelijkheid in de klasse initialiserend). Dit stelt ons in staat om de afhankelijkheid aan te roepen en deze vervolgens als volgt door te geven aan de TextEditor-klasse:

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

Nu de client het maken van de TextEditorKlasse heeft controle over welke SpellCheckerImplementatie om te gebruiken omdat we de afhankelijkheid in de TextEditorhandtekening injecteren .

2, Autoriteit 41%

Inversion of Control is wat u krijgt wanneer uw programma callbacks, b.v. zoals een GUI-programma.

Bijvoorbeeld, in een oud schoolmenu, hebt u misschien:

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

Dien daarbij de stroom van gebruikersinteractie.

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

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 bediening omgekeerd … In plaats van de computer die gebruikersinvoer in een vaste volgorde accepteert, regelt de gebruiker de volgorde waarin de gegevens worden ingevoerd en wanneer de gegevens in de database worden opgeslagen.

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

3, Autoriteit 26%

Wat is de inversie van de besturing?

Als u deze eenvoudige twee stappen volgt, hebt u de inversie van besturing gedaan:

afzonderlijk wat -d-doen deel uit wanneer -d-do deel.
Zorg ervoor dat wanneer deel kent als weinig mogelijk over wat deel; en vice versa.

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

–

De -inversie deel van de inversie van besturing (IOC) is het verwarrende ding; Omdat Inversion de relatieve term is. De beste manier om IOC te begrijpen is om dat woord te vergeten!

–

Voorbeelden

Evenementbehandeling. Gebeurtenishandelaars (what-to-do deel) – het verhogen van gebeurtenissen (wanneer-to-do deel)
-afhankelijkheidsinjectie. Code die een afhankelijkheid (what-to-do deel) construeert – het instantiëren en injecteren van die afhankelijkheid van de klanten wanneer dat nodig is, die gewoonlijk wordt verzorgd door de DI-gereedschappen zoals dolk (wanneer-toets).
-interfaces. Componentclient (wanneer-to-do deel) – Componentinterface-implementatie (what-to-do deel)
XUNIT-armatuur. Setup en TearDown (What-to-Do Part) – Xunit Frameworks roept aan het begin aan het begin en de scheuring aan het einde (wanneer-to-do deel)
Sjabloonmethode ontwerppatroon. Sjabloonmethode Wanneer-to-do deel – primitieve subklasse implementatie What-to-do deel
DLL-containermethoden in COM. Dllmain, dllcanunload, enz. (What-to-do deel) – COM / OS (wanneer-to-do deel)

4, Autoriteit 11%

Inversie van bedieningselementen gaat over het scheiden van bezorgdheid.

zonder IOC : u hebt een laptop computer en u verbreekt per ongeluk het scherm. En DARN, u vindt hetzelfde model Laptopscherm nergens in de markt. Dus je zit vast.

met IOC : u hebt een Desktop Computer en u verbreekt per ongeluk het scherm. Je merkt dat je bijna elke desktop-monitor van de markt kunt pakken en het werkt goed met je desktop.

Uw desktop implementeert met succes IOC in dit geval. Het accepteert een verscheidenheidstype monitoren, terwijl de laptop niet, het heeft een specifiek scherm nodig om vast te zijn.

5, Autoriteit 8%

Inversion of Control, (of IOC), gaat over Freedom (je gaat trouwen, je verloor vrijheid en je wordt gecontroleerd. Je hebt geëffend, je hebt zojuist de controle geïmplementeerd. Dat is wat We belden, “ontklend”. Good computersysteem ontmoedigt een zeer hechte relatie.) Meer flexibiliteit (de keuken in uw kantoor serveert alleen schoon kraanwater, dat is uw enige keuze als u wilt drinken. Baas geïmplementeerde inversie van besturing door een nieuw koffiezetapparaat in te stellen. Nu krijg je de flexibiliteit om kraanwater of koffie te kiezen.) En minder afhankelijkheid (je partner heeft een baan, je hebt geen baan Job, u bent financieel afhankelijk van uw partner, dus u wordt gecontroleerd. U vindt een baan, u hebt de controle inversie geïmplementeerd. Good computersysteem stimuleert in-afhankelijkheid.)

Wanneer u een desktopcomputer gebruikt, hebt u slaaf (of te zeggen, gecontroleerd). Je moet voor een scherm zitten en ernaar kijken. Het toetsenbord gebruiken om de muis te typen en te gebruiken om te navigeren. En een slecht geschreven software kan je nog meer slaven. Als u uw bureaublad vervangt met een laptop, dan u enigszins omgekeerde controle. Je kunt het gemakkelijk nemen en bewegen. Dus nu kunt u bepalen waar u bij bent met uw computer, in plaats van uw computer die het controleert.

Door het implementeren van de omschrijving, krijgt een software / objectconsument meer controles / opties via de software / objecten, in plaats van gecontroleerd 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 Consumer een geavanceerd raamwerk. Dat betekent dat de code die u hebt gemaakt niet alleen wordt opgeroepen. Laten we nu uitleggen waarom op deze manier beter werkt voor een webtoepassing.

Stel dat uw code een groep werkers is. Ze moeten een auto bouwen. Deze arbeiders hebben een plek en gereedschap (een softwareraamwerk) nodig om de auto te bouwen. Een traditioneelsoftwareframework zal zijn als een garage met veel tools. De arbeiders moeten dus zelf een plan maken en de gereedschappen gebruiken om de auto te bouwen. Het bouwen van een auto is geen gemakkelijke zaak, het zal voor de arbeiders heel moeilijk zijn om goed te plannen en samen te werken. Een modernsoftwareframework 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, zij 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 (raamwerk noemt uw code). De werknemers moeten alleen flexibel genoeg zijn om alle tools te gebruiken die de managers hen geven (met behulp van Dependency Injection).

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

Moderne webapplicaties met een MVC-architectuur zijn afhankelijk van het framework om URL-routering uit te voeren en controllers op hun plaats te zetten zodat het framework kan worden aangeroepen.

Dependency Injection en Inversion of Control zijn gerelateerd. Afhankelijkheidsinjectie bevindt zich op het micro-niveau en Inversion of Control bevindt zich op het macro-niveau. Je moet elke hap eten (implementeer DI) om een maaltijd af te maken (implementeer IoC).

Antwoord 6, autoriteit 5%

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

Pluspunten:

Uw code wordt ontkoppeld, zodat u eenvoudig implementaties van een interface kunt uitwisselen met alternatieve implementaties
Het is een sterke motivator om te coderen tegen interfaces in plaats van implementaties
Het is heel gemakkelijk om unit-tests voor je code te schrijven, omdat het van niets anders afhangt dan de objecten die het accepteert in zijn constructor/setters en je kunt ze gemakkelijk initialiseren met de juiste objecten afzonderlijk.

Nadelen:

IoC keert niet alleen de besturingsstroom in je programma om, het vertroebelt het ook aanzienlijk. Dit betekent dat je niet langer gewoon je code kunt lezen en van de ene plaats naar de andere kunt springen omdat de verbindingen die normaal in je code zouden zitten niet meer in de code zitten. In plaats daarvan is het in XML-configuratiebestanden of annotaties en in de code van uw IoC-container die deze metadata interpreteert.
Er ontstaat een nieuwe klasse bugs waarbij je XML-configuratie of je annotaties verkeerd zijn en je veel tijd kunt besteden aan het uitzoeken waarom je IoC-container onder bepaalde omstandigheden een null-referentie in een van je objecten injecteert.

Persoonlijk zie ik de sterke punten van IoC en ik vind ze echt leuk, maar ik heb de neiging om IoC waar mogelijk te vermijden, omdat het je software verandert in een verzameling klassen die niet langer een “echt” programma vormen, maar gewoon iets dat moet worden samengesteld door XML-configuratie of annotatiemetadata en zou zonder deze uit elkaar vallen (en uit elkaar vallen).

Antwoord 7, autoriteit 4%

Wikipedia-artikel. Voor mij is inversie van controle het omzetten van uw sequentieel geschreven code 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 aangeroepen wanneer bepaalde dingen gebeuren.
Het lost codeduplicatie op. Vroeger schreef u bijvoorbeeld handmatig uw eigen gebeurtenislus, waarbij u de systeembibliotheken voor nieuwe gebeurtenissen ondervroeg. Tegenwoordig vertel je met de meeste moderne API’s de systeembibliotheken eenvoudig in welke gebeurtenissen je geïnteresseerd bent, en het zal je laten weten wanneer ze plaatsvinden.
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 stukje van de code verandert, kunt u overwegen dit aan te pakken met inversie van controle. Het omkeren van de besturing wordt in veel talen gemakkelijk gemaakt door het concept van afgevaardigden, interfaces of zelfs onbewerkte functiewijzers.

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

Antwoord 8, autoriteit 3%

Stel dat je een object bent. En je gaat naar een restaurant:

Zonder IoC: je vraagt om “appel”, en je krijgt altijd appel voorgeschoteld als je meer vraagt.

Met IoC: u kunt om “fruit” vragen. Je kunt elke keer dat je wordt geserveerd verschillende soorten fruit krijgen. bijvoorbeeld appel, sinaasappel of watermeloen.

Dus natuurlijk heeft IoC de voorkeur als je van de variëteiten houdt.

Antwoord 9, autoriteit 3%

Maar ik denk dat je er heel voorzichtig mee moet zijn. Als je dit patroon te veel gebruikt, maak je een heel ingewikkeld ontwerp en zelfs nog ingewikkelder code.

Zoals in dit voorbeeld met TextEditor: als je maar één SpellChecker hebt, is het misschien niet echt nodig om IoC te gebruiken? Tenzij je unit-tests moet schrijven of zoiets …

Hoe dan ook: wees redelijk. Ontwerppatroon zijn goede praktijkenmaar geen Bijbel om te prediken. Plak het niet overal.

Antwoord 10, autoriteit 3%

IoC / DI duwt voor mij afhankelijkheden naar de aanroepende objecten. Super simpel.

Het niet-technische antwoord is dat je een motor in een auto kunt verwisselen vlak voordat je hem aanzet. Als alles goed aansluit (de interface), zit je goed.

Antwoord 11, autoriteit 2%

Alleen het eerste deel beantwoorden.
Wat is het?

Inversion of Control (IoC) betekent het creëren van instanties van afhankelijkheden als eerste en laatste instantie van een klasse (optioneel door ze te injecteren via de constructor), in plaats van eerst een instantie van de klasse te maken en vervolgens de klasseninstantie die instanties van afhankelijkheden maakt.
Dus, inversie van controle inverteertde stroom van controlevan het programma. In plaats vande aanroeper diede stroom van controlebestuurt (terwijl hij afhankelijkheden creëert), bestuurt de aanroeper de controlestroom van het programma.

Antwoord 12

Inversie van besturing is een patroon dat wordt gebruikt voor het ontkoppelen van componenten en lagen in het systeem. Het patroon wordt geïmplementeerd door afhankelijkheden in een component te injecteren wanneer deze wordt geconstrueerd. Deze afhankelijkheden worden meestal geleverd als interfaces voor verdere ontkoppeling en ter ondersteuning van de testbaarheid. IoC / DI-containers zoals Castle Windsor, Unity zijn tools (bibliotheken) die kunnen worden gebruikt voor het leveren van IoC. Deze tools bieden uitgebreide functies die verder gaan dan eenvoudig afhankelijkheidsbeheer, inclusief levensduur, AOP / onderschepping, beleid, enz.
a. Zorgt ervoor dat een component niet verantwoordelijk is voor het beheren van zijn afhankelijkheden.
B. Biedt de mogelijkheid om afhankelijkheidsimplementaties in verschillende omgevingen te wisselen.
C. Hiermee kan een component worden getest door middel van het bespotten van afhankelijkheden.
NS. Biedt een mechanisme voor het delen van bronnen binnen een applicatie.
a. Cruciaal bij testgestuurde ontwikkeling. Zonder IoC kan het moeilijk zijn om te testen, omdat de te testen componenten sterk gekoppeld zijn aan de rest van het systeem.
B. Cruciaal bij het ontwikkelen van modulaire systemen. Een modulair systeem is een systeem waarvan de componenten kunnen worden vervangen zonder dat hercompilatie nodig is.
C. Van cruciaal belang als er veel transversale problemen zijn die moeten worden aangepakt, met name in een bedrijfstoepassing.

Antwoord 13

Laten we zeggen dat we een afspraak hebben in een hotel.

Veel mensen, veel karaffen water, veel plastic bekers.

Als iemand wil drinken, vult ze de beker, drinkt ze en gooit ze de beker op de grond.

Over een uur of zo hebben we een vloer vol plastic bekers en water.

Laat de controle omkeren.

Dezelfde bijeenkomst op dezelfde plek, maar in plaats van plastic bekers hebben we een ober met één glazen beker (Singleton)

en ze biedt gasten altijd aan om te drinken.

Als iemand wil drinken, haalt ze uit het kelnerglas, drinkt het en geeft het terug aan de kelner.

Afgezien van de kwestie van de hygiënische, laatste vorm van controle van het drinkproces is veel effectiever en economischer.

En dit is precies wat de Spring (een andere IoC-container, bijvoorbeeld: Guice) doet. In plaats van de applicatie te laten maken wat het nodig heeft met behulp van een nieuw trefwoord (plastic beker nemen), biedt Spring IoC-container altijd aan om hetzelfde exemplaar (singleton) van het benodigde object (glas water) toe te passen.

Denk aan jezelf als organisator van zo’n bijeenkomst. U hebt de manier nodig om een bericht naar de hoteladministratie te sturen dat

leden van de vergadering hebben een glas water nodig, maar geen fluitje van een cent.

Voorbeeld:-

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
}

handige links: –

14

Taak # 1 is bijvoorbeeld om object te maken.
Zonder IOC-concept wordt taak # 1 verondersteld door programmeur te worden gedaan. Maar met IOC-concept zou taak # 1 per container worden gedaan.

In korte bediening wordt omgekeerd van programmeur naar container. Dus, het wordt genoemd als inversie van controle.

Ik heb een goed voorbeeld gevonden hier .

15

Ik vond een heel duidelijk voorbeeld hier die uitlegt hoe de ‘controle is omgekeerd ‘.

Classic-code (zonder afhankelijkheidsinjectie)

Hier is hoe een code die geen DI gebruikt ongeveer zal werken:

Applicatie heeft Foo nodig (bijvoorbeeld een controller), dus:
Applicatie maakt Foo
Applicatie roept Foo . op
- Foo heeft Bar nodig (bijvoorbeeld een dienst), dus:
- Foo maakt balk
- Foo roept Bar
  - Bar heeft Bim nodig (een service, een repository, …), dus:
  - Bar maakt Bim
  - Bar doet iets

Injectie met afhankelijkheid gebruiken

Hier is hoe een code die DI gebruikt ongeveer zal werken:

Applicatie heeft Foo nodig, die Bar nodig heeft, die Bim nodig heeft, dus:
Applicatie maakt Bim
Applicatie maakt Bar en geeft het een Bim
Applicatie maakt Foo en geeft het Bar
Applicatie roept Foo . op
- Foo roept Bar
  - Bar doet iets

De controle over de afhankelijkheden wordt omgekeerd van degene die wordt gebeld naar degene die belt.

Welke problemen lost het op?

Dependency-injectie maakt het gemakkelijk om te wisselen met de verschillende implementaties van de geïnjecteerde klassen. Tijdens het testen van eenheden kun je een dummy-implementatie injecteren, wat het testen een stuk eenvoudiger maakt.

Bijvoorbeeld: stel dat uw applicatie het door de gebruiker geüploade bestand opslaat in de Google Drive, met DI kan uw controllercode er als volgt uitzien:

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) {}
}

Wanneer uw vereisten wijzigt, wordt u in plaats van Googledrive u gevraagd om de Dropbox te gebruiken. U hoeft alleen een Dropbox-implementatie te schrijven voor de StorageserviceFace. U hebt geen wijzigingen in de controller doen zolang de implementatie van Dropbox hecht aan de Storageservice-interface.

Tijdens het testen kunt u de spot maken voor de StorageserviceFace met de dummy-implementatie waarbij alle methoden null retourneren (of elke vooraf gedefinieerde waarde volgens uw testvereisten).

In plaats daarvan als u de controlleringsklasse had om het opslagobject te construeren met de newtrefwoord als deze:

class SomeController
{
    private $storage;
    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }
    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

Wanneer u wilt wijzigen met de implementatie Dropbox, moet u alle regels vervangen waar newGoogledRiveService-object is geconstrueerd en de DropboxService gebruikt. Trouwens bij het testen van de SomeController-klasse verwacht de constructor altijd de Googledriveservice-klasse en de daadwerkelijke methoden van deze klasse worden geactiveerd.

Wanneer is het geschikt en wanneer niet?
Naar mijn mening gebruik je di wanneer je denkt dat er (of er kan zijn) alternatieve implementaties van een klasse.

16

Het lijkt erop dat het meest verwarrende ding over “IOC” het acroniem en de naam waarvoor het staat, is dat het te glamoureus is van een naam – bijna een geluidsnaam.

Hebben we echt een naam nodig om het verschil te beschrijven tussen procedurele en evenementengestuurde programmering? Ok, als we dat nodig hebben, maar moeten we een gloednieuwe “grotere dan leven” -naam kiezen die meer in verwarring is dan het oplost?

17

Inversie van controleis wanneer je naar de supermarkt gaat en je vrouw geeft je de lijst met producten die je moet kopen.

In programmeertermen gaf ze een callback-functie getProductList()door aan de functie die je uitvoert – doShopping().

Hiermee kan de gebruiker van de functie sommige delen ervan definiëren, waardoor deze flexibeler wordt.

Antwoord 18

Ik begrijp dat het antwoord hier al is gegeven. Maar ik denk nog steeds dat sommige basisprincipes over de inversie van controle hier uitgebreid moeten worden besproken voor toekomstige lezers.

Inversion of Control (IoC) is gebouwd op een heel eenvoudig principe genaamd Hollywood Principle. En er staat dat,

Bel ons niet, wij bellen u

Wat het betekent is dat je niet naar Hollywood gaat om je droom te vervullen, maar als je het waard bent, dan zal Hollywood je vinden en je droom laten uitkomen. Vrijwel omgekeerd, hè?

Als we het hebben over het principe van IoC, vergeten we Hollywood. Voor IoC moeten er drie elementen zijn, een Hollywood, jij en een taak om je droom te vervullen.

In onze programmeerwereld vertegenwoordigt Hollywoodeen generiek raamwerk (kan door jou of iemand anders zijn geschreven), jijvertegenwoordigt de gebruikerscode die je hebt geschreven en de taakstaat voor wat u met uw code wilt bereiken. Nu ga je nooit meer zelf je taak uitvoeren, niet in IoC! In plaats daarvan heb je alles zo ontworpen dat je raamwerk je taak voor je zal activeren. Zo heb je een herbruikbaar raamwerk gebouwd dat van iemand een held of van een ander een schurk kan maken. Maar dat raamwerk heeft altijd de leiding, het weet wanneer het iemand moet kiezen en dat iemand alleen weet wat het wil zijn.

Een real life-voorbeeld zou hier worden gegeven. Stel dat u een webtoepassing wilt ontwikkelen. Dus, u creëert een raamwerk dat alle gewone dingen zal aangaan die een webtoepassing moet verwerken als het hanteren van HTTP-aanvraag, het maken van het menu van de toepassing, het dienen van pagina’s, het beheren van cookies, het activeren van evenementen enz.

En dan laat u een aantal haken in uw raamwerk achter waar u verdere codes kunt plaatsen om aangepast menu, pagina’s, cookies of logging van enkele gebruikersevenementen enz. Op elk browserverzoek, wordt uw framework uitgevoerd en voert uw aangepaste codes uit en voert u uw aangepaste codes uit Serveer het terug naar de browser.

Dus, het idee is vrijwel eenvoudig. In plaats van een gebruikerstoepassing te maken die alles zal besturen, creëer je eerst een herbruikbaar raamwerk dat alles controleert en schrijf dan je aangepaste codes en haak het aan het raamwerk om die op tijd uit te voeren.

Laravel en EJB zijn voorbeelden van dergelijke kaders.

Referentie:

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

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

19

Inversie van besturing is een generiek principe, terwijl de injectie van de afhankelijkheid dit principe realiseert als een ontwerppatroon voor de constructie van het objectgrafiek (dwz configuratie controleert hoe de objecten op elkaar verwijzen, in plaats van het object zelf controleert in plaats van het object zelf object).

Kijken naar inversie van besturing als een ontwerppatroon, moeten we kijken naar wat we inverteren. Afhankelijkheid Injectie Inverts Controle van het construeren van een grafiek van objecten. Indien verteld in de termijn van de leilman, impliceert de omkering van de controle verandering in stroom van controle in het programma. Bijv. In de traditionele Standalone-app hebben we de hoofdmethode, vanwaar het besturingselement wordt doorgegeven aan andere bibliotheken van derden (in het geval, hebben we de functie van derden bibliotheek gebruikt), maar door inversie van besturingsregeling wordt overgedragen van de bibliotheekcode van derden naar onze Code , want we nemen de service van bibliotheek van derden. Maar er zijn andere aspecten die in een programma moeten worden omgekeerd – b.v. aanroepen van methoden en discussies om de code uit te voeren.

Voor diegenen die geïnteresseerd zijn in meer diepgang op de inversie van besturing is een paper gepubliceerd om een vollediger beeld van de omkering van de besturing als een ontwerppatroon (OfficeFloor: met behulp van kantoorpatronen om softwareontwerp http://doi.acm.org/10.1145/2739011.2739013 met een gratis exemplaar beschikbaar om te downloaden van http://www.officefloor.net/about.html ).

Wat wordt geïdentificeerd, is de volgende relatie:

Inversie van besturing (voor methoden) = afhankelijkheid (status) injectie + voortzetting injectie + draadinjectie

Samenvatting van de bovenstaande relatie voor inversie van besturing beschikbaar – http://dzone.com/ artikelen / inversie-of-coupling-control

20

Een zeer eenvoudige schriftelijke uitleg vindt u hier

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

Er staat –

“Elke niet-triviale toepassing bestaat uit twee of meer klassen die
met elkaar samenwerken om wat bedrijfslogica uit te voeren.
Traditioneel is elk object verantwoordelijk voor het verkrijgen van zijn eigen
verwijzingen naar de objecten waarmee het samenwerkt (de afhankelijkheden).
Bij het toepassen van DI krijgen de objecten hun afhankelijkheden bij het maken
tijd door een externe entiteit die elk object in de
systeem. Met andere woorden, afhankelijkheden worden in objecten geïnjecteerd.”

Antwoord 21

IoC gaat over het omkeren van de relatie tussen uw code en code van derden (bibliotheek/framework):

Bij normale s/w-ontwikkeling schrijft u de methode main()en roept u de “bibliotheek”-methoden aan. Jijhebt de controle 🙂
In IoC bestuurt het “framework” main()en roept het uw methoden aan. Het Frameworkheeft de controle 🙁

DI (Dependency Injection) gaat over hoe de controle in de applicatie stroomt. Traditionele desktopapplicaties hadden de controlestroom van uw applicatie (main()-methode) naar andere bibliotheekmethodeaanroepen, maar met DI-controlestroom wordt omgekeerd, dat is het framework dat zorgt voor het starten van uw app, het initialiseren en het aanroepen van uw methoden wanneer dat nodig is.

Uiteindelijk win je altijd 🙂

Antwoord 22

Ik vind deze uitleg leuk: http:// joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Het begint eenvoudig en toont ook codevoorbeelden.

De consument, X, heeft de geconsumeerde klasse, Y nodig, om iets te bereiken. Dat is allemaal goed en natuurlijk, maar moet x echt weten dat het y gebruikt?

is het niet genoeg dat X weet dat het iets gebruikt dat het gedrag heeft, de methoden, eigenschappen etc, van y zonder te weten wie het gedrag daadwerkelijk implementeert?

Door een abstracte definitie te halen van het gedrag dat wordt gebruikt door x in y, geïllustreerd als ik hieronder, gebruik en laat de consument x een instantie van dat gebruiken in plaats van y het kan blijven doen wat het doet zonder de details over te hoeven weten. Y.

In de afbeelding hierboven is implementeren I en X gebruikt een exemplaar van I. Hoewel het heel goed mogelijk is dat X nog steeds gebruikt, wat interessant is, is dat X dat niet weet. Het weet gewoon dat het iets gebruikt dat ik implementeert.

Lees artikel voor verdere informatie en beschrijving van voordelen, zoals:

X is niet meer afhankelijk van y
flexibeler, implementatie kan worden beslist in runtime
isolatie van code-eenheid, gemakkelijker testen

…

23

Programmering spreken

IOC in eenvoudige bewoordingen: het is het gebruik van interface als een manier van specifiek iets (een dergelijk veld of een parameter) als jokerteken dat kan worden gebruikt door sommige klassen. Hiermee kan de re-bruikbaarheid van de code.

Laten we bijvoorbeeld zeggen dat we twee klassen hebben: Honden Kat. Beide delen dezelfde kwaliteiten/toestanden: leeftijd, grootte, gewicht. Dus in plaats van een serviceklasse te maken met de naam DogServiceen CatService, kan ik een enkele maken met de naam AnimalServicewaarmee alleen Dog and Cat kan worden gebruikt als ze de interface IAnimalgebruiken.

Pragmatisch gesproken heeft het echter een aantal keerzijden.

a) De meeste ontwikkelaars weten niet hoe ze het moeten gebruiken. Ik kan bijvoorbeeld een klasse maken met de naam Klanten Ik kan automatisch(met behulp van de tools van de IDE) een interface maken met de naam ICustomer. Het is dus niet zeldzaam om een map vol klassen en interfaces te vinden, ongeacht of de interfaces opnieuw worden gebruikt of niet. Het heet BLOATED. Sommige mensen zouden kunnen beweren dat “we het in de toekomst misschien kunnen gebruiken”. 😐

b) Het heeft enkele beperkingen. Laten we het bijvoorbeeld hebben over Honden Katen ik wil een nieuwe service (functionaliteit) alleen voor honden toevoegen. Laten we zeggen dat ik het aantal dagen wil berekenen dat ik een hond moet trainen (trainDays()), voor katten is het nutteloos, katten kunnen niet worden getraind ( Ik maak een grapje).

b.1) Als ik trainDays()toevoeg aan de Service AnimalService, dan werkt het ook met katten en is het helemaal niet geldig.

b.2) Ik kan een voorwaarde toevoegen in trainDays()waar het evalueert welke klasse wordt gebruikt. Maar het zal de IoC volledig breken.

b.3) Ik kan een nieuwe serviceklasse aanmaken met de naam DogServicealleen voor de nieuwe functionaliteit. Maar het zal de onderhoudbaarheid van de code vergroten omdat we twee serviceklassen (met vergelijkbare functionaliteit) voor Hondzullen hebben en het is slecht.

Antwoord 24

Omdat er al veel antwoorden op de vraag zijn, maar geen van deze de uitsplitsing van de term Inversion Control laat zien, zie ik een mogelijkheid om een beknopter en nuttiger antwoord te geven.

Inversion of Control is een patroon dat het Dependency Inversion Principle (DIP) implementeert. DIP stelt het volgende: 1. Modules op hoog niveau mogen niet afhankelijk zijn van modules op laag niveau. Beide moeten afhankelijk zijn van abstracties (bijv. interfaces). 2. Abstracties mogen niet afhankelijk zijn van details. Details (concrete implementaties) moeten afhankelijk zijn van abstracties.

Er zijn drie soorten Inversie van Controle:

Interface-inversie
Providers mogen geen interface definiëren. In plaats daarvan moet de consument de interface definiëren en moeten providers deze implementeren. Interface-inversie maakt het mogelijk om de noodzaak te elimineren om de consument elke keer aan te passen wanneer een nieuwe provider wordt toegevoegd.

Stroominversie
Wijzigt de besturing van de stroom. U hebt bijvoorbeeld een consoletoepassing waar u om veel parameters hebt gevraagd en na elke ingevoerde parameter moet u op Enter drukken. U kunt Flow Inversion hier toepassen en een desktoptoepassing implementeren waar de gebruiker de volgorde van het invoeren van parameters kan kiezen, de gebruiker parameters kan bewerken en bij de laatste stap hoeft de gebruiker slechts eenmaal op Enter te drukken.

Inversie creëren
Het kan worden geïmplementeerd door de volgende patronen: fabriekspatroon, servicelocator en afhankelijkheidsinjectie. Creation Inversion helpt om afhankelijkheden tussen typen te elimineren, waardoor het proces van het maken van afhankelijkheidsobjecten buiten het type wordt verplaatst dat deze afhankelijkheidsobjecten gebruikt. Waarom zijn afhankelijkheden slecht? Hier zijn een paar voorbeelden: het direct aanmaken van een nieuw object in je code maakt het testen moeilijker; het is onmogelijk om referenties in assemblages te wijzigen zonder opnieuw te compileren (OCP-principeschending); je kunt een desktop-UI niet gemakkelijk vervangen door een web-UI.

Antwoord 25

Inversie van controle gaat over het overdragen van controle van bibliotheek naar de client. Het is logischer als we het hebben over een client die een functiewaarde (lambda-expressie) injecteert (doorgeeft) in een functie van hogere orde (bibliotheekfunctie) die het gedrag van de bibliotheekfunctie bestuurt (verandert).

Dus een eenvoudige implementatie (met enorme implicaties) van dit patroon is een bibliotheekfunctie van hogere orde (die een andere functie als argument accepteert).

Bibliotheekfuncties zoals “map”, “flatMap” zijn bijvoorbeeld IoC-implementaties.

Een client of framework dat bibliotheekafhankelijkheden (die gedrag dragen) in bibliotheken injecteert, kan ook als IoC worden beschouwd

Antwoord 26

Ik heb hier veel antwoorden op gelezen, maar als iemand nog steeds in de war is en een extra “lekenterm” nodig heeft om IoC uit te leggen, dan is dit mijn mening:

Stel je een ouder en kind voor die met elkaar praten.

Zonder IoC:

*Ouder: je kunt alleen spreken als ik je vragen stel en je kunt alleen handelen als ik je toestemming geef.

Ouder: dit betekent dat je me niet kunt vragen of je mag eten, spelen, naar de wc mag of zelfs mag slapen als ik het je niet vraag.

Ouder: wil je eten?

Kind: Nee.

Ouder: Oké, ik kom zo terug. Wacht op mij.

Kind: (wil spelen, maar aangezien er geen vraag van de ouder is, kan het kind niets doen).

Na 1 uur…

Ouder: ik ben terug. Wil je spelen?

Kind: Ja.

Ouder: toestemming verleend.

Kind: (kan eindelijk spelen).

Dit eenvoudige scenario legt uit dat de besturing is gericht op de ouder. De vrijheid van het kind is beperkt en hangt sterk af van de vraag van de ouder. Het kind mag ALLEENspreken wanneer hem wordt gevraagd te spreken, en kan ALLEENhandelen wanneer toestemming wordt verleend.

Met IoC:

Het kind heeft nu de mogelijkheid om vragen te stellen en de ouder kan antwoorden met antwoorden en machtigingen. Betekent eenvoudig dat de besturing is omgekeerd!
Het kind is nu vrij om op elk moment vragen te stellen en hoewel er nog steeds afhankelijkheid is met de ouder met betrekking tot toestemmingen, is hij niet afhankelijk in de manier van spreken/vragen.

In een technologische manier om uit te leggen, lijkt dit erg op console/shell/cmd versus GUI-interactie. (Dat is het antwoord van Mark Harrison boven nr. 2 topantwoord).
In console ben je afhankelijk van wat er aan je wordt gevraagd/weergegeven en kun je niet naar andere menu’s en functies springen zonder eerst de vraag te beantwoorden; volgens een strikte sequentiële stroom. (programmatisch is dit als een methode/functie-lus).
Met GUI zijn de menu’s en functies echter overzichtelijk en kan de gebruiker alles selecteren wat hij nodig heeft, waardoor hij meer controleheeft en minder beperkt is. (programmatisch, menu’s worden teruggebeld wanneer ze zijn geselecteerd en er vindt een actie plaats).

Antwoord 27

Als u IoC gebruikt, maakt u uw objecten niet nieuw. Uw IoC-container doet dat en beheert de levensduur ervan.

Het lost het probleem op van het handmatig veranderen van elke instantiatie van het ene type object naar de andere.

Het is geschikt wanneer u functionaliteit hebt die in de toekomst kan veranderen of die anders kan zijn, afhankelijk van het milieu of de configuratie die wordt gebruikt.

28

Om het concept te begrijpen, inversie van controle (IOC) of afhankelijkheidsinversieprincipe (DIP) omvat twee activiteiten: abstractie en inversie.
Afhankelijkheid Injectie (DI) is slechts een van de weinige van de inversiemethoden.

Om hier meer over te lezen, kunt u mijn blog lezen Hier

Wat is het?

Het is een oefening waarin je het daadwerkelijke gedrag laat komen van buiten de grens (klasse in objectgeoriënteerde programmering). De grensentiteit kent de abstractie (E.G-interface, abstracte klasse, afgevaardigde in objectgeoriënteerde programmering) ervan.

Welke problemen lost het op?

Tijdens de programmering probeert IOC de monolithische code op te lossen door het modulair te maken, verschillende delen ervan te ontkoppelen en het eenheid-testbaar maken.

Wanneer is het geschikt en wanneer niet?

Het is het grootste deel van de tijd geschikt, tenzij u situaties hebt waar u gewoon een monolithische code wilt (E.G zeer eenvoudig programma)

Wat is inversie van controle?