Wat is Inversion of Control?

stemmen
1k

Inversion of Control (of IOC) kan heel verwarrend zijn wanneer het eerst wordt aangetroffen.

  1. Wat is het?
  2. Welke problemen doet het op te lossen?
  3. Wanneer is het nodig en wanneer niet?
De vraag is gesteld op 06/08/2008 om 04:35
bron van user
In andere talen...                            


32 antwoorden

stemmen
1k

De Inversion of Control (IOC) en Dependency Injection (DI) patronen zijn allemaal over het verwijderen van afhankelijkheden van uw code.

Stel bijvoorbeeld dat uw toepassing een tekstverwerker component en u wilt spellingcontrole bieden. Uw standaard code zou er ongeveer zo uitzien:

public class TextEditor {

    private SpellChecker checker;

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

Wat we hier gedaan creëert een afhankelijkheid tussen de TextEditoren de SpellChecker. In een IOC scenario zouden we in plaats daarvan zoiets als dit:

public class TextEditor {

    private IocSpellChecker checker;

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

In de eerste code voorbeeld we instantiëren SpellChecker( this.checker = new SpellChecker();), wat betekent dat de TextEditorklas is direct afhankelijk van de SpellCheckerklasse.

In de tweede code voorbeeld maken we een abstractie door het hebben van de SpellCheckerafhankelijkheid klasse TextEditorconstructor handtekening (niet initialiseren afhankelijkheid in de klas). Dit stelt ons in staat om de afhankelijkheid noemen dan doorgeven aan de tekstverwerker klasse als volgt:

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

Nu is de cliënt het creëren van de TextEditorklasse heeft de controle over welke SpellCheckeruitvoering te gebruiken omdat we de afhankelijkheid aan het injecteren TextEditorhandtekening.

Dit is slechts een eenvoudig voorbeeld, er is een goede reeks van artikelen door Simone Busoli dat het onderdeel nader toegelicht.

antwoordde op 06/08/2008 om 08:22
bron van user

stemmen
485

Inversion of Control is wat je krijgt als je programma callbacks, bijvoorbeeld als een gui programma.

Bijvoorbeeld, in een oude school menu, moet u:

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

waardoor de stroom van gebruikersinteractie regelen.

In een GUI programma of somesuch, 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

Nu zeggenschap omgekeerd ... in plaats van het accepteren van gebruikersinvoer computer in een vaste volgorde, de gebruiker bestuurt de volgorde waarin de gegevens worden ingevoerd, en wanneer de data wordt opgeslagen in de database.

In principe alles met een gebeurtenissenlus, callbacks, of uitvoeren triggers valt in deze categorie.

antwoordde op 06/08/2008 om 06:42
bron van user

stemmen
356

Wat is Inversion of Control?

Als u deze eenvoudige twee stappen te volgen, heb je inversie van controle verricht:

  1. Aparte welk deel -to-doen vanaf wanneer -to-do part.
  2. Zorg ervoor dat wanneer een deel weet zo weinig mogelijk over welk deel; en vice versa.

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

-

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

-

Voorbeelden

  • Event Handling. Event Handlers (what-to-do deel) - Het verhogen van Evenementen (when-to-do part)
  • Interfaces. Component client (when-to-do deel) - Component Interface implementatie (what-to-do part)
  • xUnit fixure. Setup en TearDown (what-to-do deel) - xUnit kaders oproepen naar Setup aan het begin en demontage aan het eind (als-to-do part)
  • Templaatmethode ontwerppatroon. template methode wanneer-to-do part - primitieve subklasse implementatie what-to-do part
  • DLL container werkwijzen COM. DllMain, DllCanUnload, etc (wat-to-do deel) - COM / OS (when-to-do part)
antwoordde op 22/07/2010 om 18:34
bron van user

stemmen
81

Omkering van Controls gaat over het scheiden van zorgen.

Zonder IOC : U hebt een laptop computer en u per ongeluk het scherm te breken. En stop, vind je hetzelfde model laptop scherm is nergens in de markt. Dus zit je vast.

Met IOC : U hebt een desktop computer en u per ongeluk het scherm te breken. Je merkt dat je kunt net pak bijna elke desktop monitor uit de markt, en het werkt goed met uw desktop.

Uw desktop succesvol toe te passen IOC in dit geval. Het kan diverse soorten monitors, terwijl de laptop niet, het moet een specifiek scherm vast te krijgen.

antwoordde op 25/09/2013 om 15:24
bron van user

stemmen
77

Inversion of Control, (of IOC), is over het krijgen van de vrijheid (je trouwen, je verloren vrijheid en je wordt gecontroleerd. U gescheiden, heb je zojuist geïmplementeerd Inversion of Control. Dat is wat wij noemen, "ontkoppeld". Good computersysteem ontmoedigt een aantal zeer nauwe relatie.) meer flexibiliteit (de keuken in uw kantoor alleen dient schoon leidingwater, dat is uw enige keuze wanneer je wilt drinken. je baas geïmplementeerd Inversion of control door het opzetten van een nieuw koffiezetapparaat. Nu krijg je de flexibiliteit te kiezen tussen kraanwater of koffie.) en minder afhankelijkheid (je partner heeft een baan, heb je geen baan hebt, u financieel afhankelijk van uw partner, zodat u worden geregeld. u vindt een baan, heb je geïmplementeerd Inversion van controle. Goede computer systeem moedigt in-afhankelijkheid.)

Als u een desktop computer te gebruiken, heb je gezwoegd (of zeggen, geregeld). Je moet zitten voor een scherm en kijken. Werken met het toetsenbord te typen en het gebruik van de muis om te navigeren. En een slecht geschreven software kan je nog meer slaaf. Als u uw bureaublad te vervangen door een laptop, dan moet je een beetje omgekeerde controle. U kunt gemakkelijk nemen en te verplaatsen. Dus nu kun je bepalen waar je bent met je computer, in plaats van je computer het controleren.

Door de implementatie van Inversion of Control, krijgen een software / object consument meer controle / opties op de software / objecten, in plaats van te worden geregeld of met minder opties.

Met de bovenstaande ideeën in het achterhoofd. We missen nog steeds een belangrijk onderdeel van het IOC. In het scenario van IOC, de software / object consument is een verfijnd kader. Dat betekent dat de code die u hebt gemaakt, wordt niet genoemd door uzelf. Laten we nu eens uitleggen waarom op deze manier beter voor een web-applicatie werkt.

Stel dat uw code is een groep van werknemers. Zij hebben behoefte aan om een auto te bouwen. Deze werknemers hebben behoefte aan een plek en gereedschappen (een software framework) om de auto te bouwen. Een traditionele software framework zal zijn als een garage met veel tools. Dus de werknemers moeten een plan zichzelf te maken en het gebruik van de tools om de auto te bouwen. Het bouwen van een auto is geen gemakkelijke zaak, zal het heel moeilijk zijn voor de werknemers te plannen en goed samenwerken. Een moderne software framework zal zijn als een moderne auto fabriek met alle faciliteiten en managers op zijn plaats. De werknemers niet aan een plan te maken, de managers (onderdeel van het kader, zij zijn de slimste mensen en maakte de meest geavanceerde formule) zal helpen coördineren, zodat de werknemers weten wanneer ze hun werk te doen (framework het nummer van uw code). De arbeiders hoeft alleen maar flexibel genoeg zijn om het even welke hulpmiddelen de managers geven om ze te gebruiken (met behulp van Dependency Injection) te zijn.

Hoewel de werknemers geven de controle van het beheer van het project op het hoogste niveau aan de managers (het raamwerk). Maar het is goed om te hebben sommige professionals helpen. Dit is het concept van IOC echt vandaan komen.

Modern Web applicaties met een MVC architectuur is afhankelijk van het kader om URL Routing doen en zet Controllers in de plaats voor het kader om te bellen.

Dependency Injection en Inversion of Control verwant zijn. Dependency Injection is op micro niveau Inversion of Control is bovenaan macro niveau. Je moet elke hap eten (implementeren DI) om een maaltijd (implementeren IOC) af te maken.

antwoordde op 04/03/2013 om 20:33
bron van user

stemmen
72

Voor het gebruik van Inversion of Control moet je goed op de hoogte van het feit dat het heeft zijn voor- en nadelen en je moet weten waarom je het gebruiken als je dat te doen.

Voors:

  • Uw code wordt losgekoppeld, zodat u gemakkelijk implementaties kunt uitwisselen van een interface met alternatieve implementaties
  • Het is een sterke motivatie voor het coderen tegen interfaces plaats implementaties
  • Het is heel gemakkelijk om unit tests te schrijven voor uw code omdat het afhankelijk is niets anders dan de objecten die het erkent in haar constructeur / setters en je kunt ze gemakkelijk initialiseren met de juiste objecten in isolement.

nadelen:

  • IOC keert niet alleen de control flow in uw programma, dat vertroebelt het ook aanzienlijk. Dit betekent dat u niet langer alleen lees uw code en springen van de ene plaats naar de andere, omdat de verbindingen die normaal zou zijn in de code niet in de code niet meer. In plaats daarvan is in XML configuratiebestanden of annotaties en in de code van uw IoC container die deze metadata interpreteert.
  • Er ontstaat een nieuwe klasse van bugs waar u uw XML config of annotaties verkeerd en je kunt veel tijd doorbrengen vinden waarom uw IoC container een null-verwijzing injecteert in een van uw objecten onder bepaalde voorwaarden.

Persoonlijk zie ik de sterke punten van het IOC en ik ze heel graag, maar ik de neiging om te voorkomen dat het IOC waar mogelijk, omdat het de software verandert in een verzameling van klassen die een "echte" programma, maar gewoon iets dat moet samen door worden gezet vormen niet langer XML configuratie of annotatie metadata en zou vallen (en vallen) van elkaar zonder.

antwoordde op 12/02/2010 om 15:31
bron van user

stemmen
55
  1. Wikipedia artikel . Voor mij is inversie van de controle het draaien van uw sequentieel geschreven code en draaien in een delegatie structuur. In plaats van uw programma expliciet alles controleert, het programma wordt een klasse of bibliotheek met bepaalde functies te noemen wanneer bepaalde dingen gebeuren.

  2. Het lost code duplicatie. Bijvoorbeeld, in de oude dagen zou je handmatig schrijf uw eigen evenement lus, polling het systeem bibliotheken voor nieuwe evenementen. Tegenwoordig zijn de meeste moderne API je gewoon vertellen het systeem bibliotheken welke gebeurtenissen u geïnteresseerd bent, en het zal u laten weten wanneer ze gebeuren.

  3. Inversie van controle is een praktische manier om code herhaling te verminderen, en als je merkt dat je kopiëren van een complete methode en slechts het veranderen van een klein stukje van de code, kunt u overwegen de aanpak van het met inversie van controle. Inversie van de controle is gemakkelijk in vele talen gemaakt door het concept van de afgevaardigden, interfaces, of zelfs ruwe functie pointers.

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

antwoordde op 06/08/2008 om 05:33
bron van user

stemmen
38

Maar ik denk dat je moet heel voorzichtig mee zijn. Als je dit patroon zal overmatig gebruik, zult u zeer ingewikkelde ontwerp en nog ingewikkelder code te maken.

Zoals in dit voorbeeld met TextEditor: als u slechts één SpellChecker misschien is het niet echt nodig om IoC gebruiken? Tenzij je nodig hebt om unit tests te schrijven of zoiets ...

Hoe dan ook: wees redelijk. Ontwerp patroon zijn goede praktijken , maar niet de Bijbel te worden gepredikt. Doe het niet overal plakken.

antwoordde op 06/08/2008 om 23:08
bron van user

stemmen
34

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

Zonder IOC : je vraagt voor "appel", en u bent altijd geserveerd appel wanneer u meer vragen.

Met IOC : U kunt vragen voor "fruit". U kunt verschillende vruchten te krijgen elke keer dat u geserveerd. bijvoorbeeld, appel, sinaasappel, of watermeloen.

Dus, uiteraard, het IOC heeft de voorkeur wanneer je van de rassen.

antwoordde op 25/09/2013 om 15:00
bron van user

stemmen
34

IOC / DI is voor mij duwen afhankelijkheden met de bellende objecten. Super eenvoudig.

De niet-technischer antwoord is de mogelijkheid om te wisselen van een motor in een auto vlak voordat je hem aanzet. Als alles haken rechts (de interface), je bent goed.

antwoordde op 19/09/2008 om 03:54
bron van user

stemmen
23
  1. Inversie van controle is een patroon voor ontkoppeling componenten en lagen van het systeem. Het patroon wordt uitgevoerd door injecteren afhankelijkheden in een component wanneer het wordt uitgevoerd. Deze afhankelijkheden worden gewoonlijk verschaft als interface voor ontkoppeling en testbaarheid ondersteunen. IOC / DI containers zoals Windsor Castle, Unity zijn instrumenten (bibliotheken) die kan worden gebruikt voor het verstrekken van het IOC. Deze tools bieden uitgebreide functies die verder gaan dan eenvoudige afhankelijkheid management, inclusief de levensduur, AOP / onderscheppen, beleid, etc.

  2. een. Vermindert een component van het zijn verantwoordelijk voor het beheer ervan is afhankelijkheden.
    b. Biedt de mogelijkheid om de afhankelijkheid implementaties te wisselen in verschillende omgevingen.
    c. Hiermee kan een component worden getest door middel bespotten afhankelijkheden.
    d. Voorziet in een mechanisme voor het delen van middelen in een applicatie.

  3. een. Kritische bij het doen van test-driven development. IOC zonder het moeilijk te testen kan zijn, omdat de componenten testen sterk zijn gekoppeld met de rest van het systeem.
    b. Kritische bij het ontwikkelen van modulaire systemen. Een modulair systeem is een systeem waarvan de componenten kunnen worden vervangen zonder hercompilatie.
    c. Kritische als er veel transversale thema's die moeten aangepakt, partilarly in een enterprise applicatie.

antwoordde op 19/09/2008 om 03:27
bron van user

stemmen
17

Ik zal opschrijven mijn eenvoudige begrip van deze twee termen:

For quick understanding just read examples*

Dependency Injection (DI):
Dependency injectiemiddelen algemeen leiden van een voorwerp waarop werkwijze hangt als parameter op een werkwijze, in plaats van de methode volgens welke de afhankelijke object .
Wat het betekent in de praktijk dat de methode niet direct afhankelijk is van een bepaalde implementatie; elke implementatie die voldoet aan de eisen kan worden doorgegeven als een parameter.

Met deze voorwerpen vertellen thier afhankelijkheden. En in het voorjaar beschikbaar stelt.
Dit leidt tot losgekoppelde applicatie-ontwikkeling.

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:
Dit is gemeenschappelijk kenmerk van kaders, IOC beheert java objecten
- van concretisering tot de vernietiging door middel van haar BeanFactory.
-java componenten die geïnstantieerd door het IOC container bonen genoemd en IOC container beheert scope een Bean's levenscyclus gebeurtenissen en eventuele AOP functies waarvoor deze is geconfigureerd en gecodeerd.

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.

Door de implementatie van Inversion of Control, krijgen een software / object consument meer controle / opties op de software / objecten, in plaats van wordt gecontroleerd of met minder opties.

Inversie van controle als ontwerprichtlijn beoogt het volgende:

Er is een ontkoppeling van het uitvoeren van een bepaalde taak van de uitvoering.
Elke module kan concentreren op wat het is ontworpen voor.
Modules maken geen veronderstellingen over wat andere systemen doen, maar vertrouwen op hun contracten.
Het vervangen van modules heeft geen kant effect op andere modules
ik dingen abstract hier houden, U kunt een bezoek onderstaande links voor detail begrip van het onderwerp.
Een goed boek met voorbeeld

Gedetailleerde uitleg

antwoordde op 10/11/2014 om 08:43
bron van user

stemmen
15

Bijvoorbeeld, taak # 1 is het object te maken. Zonder IOC concept, wordt de taak # 1 verondersteld te worden gedaan door Programmer.But Met IOC-concept, taak nummer 1 worden uitgevoerd door container.

In het kort Controle wordt omgekeerd van Programmer naar container. Dus, wordt het genoemd als inversie van controle.

Ik vond dat een goed voorbeeld hier .

antwoordde op 27/01/2010 om 13:15
bron van user

stemmen
14

Het beantwoorden van alleen het eerste deel. Wat is het?

Inversion of Control (IOC) middelen voor gevallen van afhankelijkheden eerste en laatste instantie van een klasse (naar keuze te hebben geïnjecteerd constructeur) te maken in plaats van een instantie van de klasse en daarna de klasse-instantie creëren van instanties van afhankelijkheden. Aldus inversie van controle keert de besturingsstroom van het programma. In plaats van de opgeroepene regelen van de besturingsstroom (tijdens het maken afhankelijkheden), de beller regelt de besturing van het programma .

antwoordde op 11/01/2016 om 00:49
bron van user

stemmen
14

Het lijkt erop dat de meest verwarrende ding over "IOC" de afkorting en de naam voor wie het betekent is dat het ook glamoureuze van een naam - bijna een geluid naam.

Hebben we echt een naam waarmee het verschil tussen procedurele en event-driven beschrijven nodig? OK, als we moeten, maar hebben we nodig om een ​​gloednieuwe "groter dan het leven" naam die meer dan het oplost verwart halen?

antwoordde op 19/01/2011 om 04:50
bron van user

stemmen
13

Laten we zeggen dat we een aantal bijeenkomst in het gehele hotel.

Veel mensen, veel karaffen van water, veel plastic bekers.

Als iemand wil drinken, ze vullen, drank en gooi cup op de vloer.

Na een uur of zo hebben we een vloer bedekt plastic bekertjes en water.

Laten we omkeren controle.

Deze vergadering op dezelfde plaats, maar in plaats van plastic bekers wij een kelner met een glazen beker (Singleton)

en ze alle tijd biedt aan de gasten drinken.

Als iemand wil drinken, krijgen ze van ober glas, drinken en vervolgens terug naar ober.

Afgezien van de vraag van de hygiënische, laatste vorm van drinken procesbeheersing is veel effectiever en economisch.

En dit is precies wat de Spring (andere IOC container, bijvoorbeeld: Guice) doet. In plaats van te laat om toepassing te maken wat het nodig heeft met behulp van nieuwe trefwoord (het nemen van plastic beker), Spring IoC container hele tijd te bieden om de toepassing dezelfde instantie (singleton) van de benodigde object (glas water).

Denk na over jezelf als organisator van deze vergadering. Je moet de weg naar een bericht naar een hotel bestuur dat

vergadering leden zullen glas water, maar niet fluitje van een cent nodig.

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:-

antwoordde op 26/09/2012 om 18:54
bron van user

stemmen
13

Ik ben het met NilObject , maar ik zou graag aan toe te voegen:

Als je merkt dat je kopiëren van een complete methode en slechts het veranderen van een klein stukje van de code, kunt u overwegen de aanpak van het met inversie van controle

Als je merkt dat je het kopiëren en plakken van code rond, je bent bijna altijd doet iets verkeerd. Gecodificeerd als het ontwerp principe slechts eenmaal .

antwoordde op 06/08/2008 om 06:20
bron van user

stemmen
10

IOC gaat over het omkeren van de relatie tussen de code en de code van derden (bibliotheek / kader):

  • In normale s / w ontwikkeling, schrijf je de main () methode en bel "library" methoden. Je bent in controle :)
  • In IOC de "framework" bestuurt main () en het nummer van uw methoden. Het Framework is in control :(

DI (Dependency Injection) is over hoe de controle stroomt in de toepassing. De traditionele desktop-applicatie hadden control flow van uw aanvraag (main () methode) naar andere bibliotheek methode oproepen, maar met DI-control flow wordt omgekeerd dat kader verzorgt het starten van uw app, te initialiseren en het aanroepen van uw methoden wanneer nodig.

Op het einde je altijd winnen :)

antwoordde op 19/09/2014 om 19:25
bron van user

stemmen
7

Inversion of Control is een generiek principe, terwijl dependency injection realiseert dit principe als een ontwerppatroon te grafiekobject constructie (bijv configuratie bepaalt hoe de objecten elkaar verwijzen, in plaats van het object zelf regelen hoe de verwijzing naar een ander object te krijgen).

Kijkend naar Inversion of Control als een ontwerp patroon, moeten we kijken naar wat we omkeren. Dependency Injection keert de controle over de bouw van een grafiek van objecten. Als verteld in termen van de leek, inversie van de controle impliceert verandering in de stroom van de controle in het programma. Bijv. In de traditionele standalone app, hebben we de belangrijkste methode, vanwaar de controle wordt doorgegeven aan een andere derde partij bibliotheken (in geval hebben we de functie van derden bibliotheek gebruikt), maar door middel van inversie van controle controle wordt overgedragen van derden bibliotheek code om onze code , omdat we het nemen van de diensten van derden bibliotheek. Maar er zijn andere aspecten die moeten worden omgekeerd binnen een programma - bijvoorbeeld aanroeping van methoden en draden om de code uit te voeren.

Voor diegenen die geïnteresseerd zijn in meer diepte op Inversion of Control een paper is gepubliceerd waarin een completer beeld van Inversion of Control als een ontwerp patroon (OfficeFloor: het gebruik van office patronen om het ontwerpen van software te verbeteren http://doi.acm.org/10.1145/ 2739011.2739013 met een gratis exemplaar te downloaden op http://www.officefloor.net/mission.html )

Wat is geïdentificeerd is de volgende relatie:

Inversion of Control (voor werkwijzen) = Dependency (state) Injectie + Voortzetting Injectie + Thread Injectie

antwoordde op 29/10/2015 om 04:27
bron van user

stemmen
7

programmeren spreken

IOC in gunstige voorwaarden: Het is het gebruik van Interface als een manier om specifiek iets (zoals een veld of een parameter) als een wildcard die gebruikt kan worden door een aantal klassen. Het laat de herbruikbaarheid van de code.

Bijvoorbeeld, laten we zeggen dat we twee klassen: Hond en Kat . Zowel deelt dezelfde kwaliteiten / luidt: leeftijd, grootte, gewicht. Dus in plaats van het creëren van een klasse van de dienst geroepen DogService en CatService , kan ik een enkele maken met de naam AnimalService die het mogelijk maakt om de hond en alleen gebruiken als ze de interface gebruiken IAnimal .

Echter, pragmatisch gezien, het heeft een aantal naar achteren.

a) De meeste van de ontwikkelaars niet weten hoe het te gebruiken . Bijvoorbeeld, kan ik een klasse met de naam te maken voor klanten en ik kan automatisch (met behulp van de instrumenten van de IDE) een interface genaamd ICustomer . Dus, het is niet zeldzaam om een map vol met klassen en interfaces, ongeacht of de interfaces niet zal worden hergebruikt of te vinden. Het heet BLOATED. Sommige mensen zou kunnen stellen dat "kan in de toekomst die we konden gebruiken." : - |

b) Het heeft een aantal limitings. Bijvoorbeeld, laten we praten over de zaak van de Hond en Kat en ik wil een nieuwe dienst (functionaliteit) toe te voegen alleen voor honden. Laten we zeggen dat ik wil het aantal dagen dat ik nodig heb om een hond (de trein te berekenen trainDays()), voor de kat het is nutteloos, katten kunnen niet worden opgeleid (ik ben een grapje).

b.1) Als ik toevoegen trainDays()aan de Dienst AnimalService dan werkt het ook met katten en het is niet geldig op alle.

b.2) Ik kan een voorwaarde toe te voegen trainDays()waar het beoordeelt welke klasse wordt gebruikt. Maar het zal volledig breken het IOC.

b.3) Ik kan een nieuwe klasse van dienst te creëren genaamd DogService alleen voor de nieuwe functionaliteit. Maar, zal het de onderhoudbaarheid van de code te verhogen, omdat we twee klassen van de dienst (met vergelijkbare functionaliteit) heeft voor de hond en het is slecht.

antwoordde op 19/04/2015 om 12:07
bron van user

stemmen
7

Een zeer eenvoudige schriftelijke toelichting is hier te vinden

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

het zegt

"Elk triviaal applicatie is opgebouwd uit twee of meer klassen die met elkaar samenwerken om een ​​aantal business logica uit te voeren. Traditioneel, elk object is verantwoordelijk voor het verkrijgen van een eigen verwijzingen naar de objecten die het samen met (de afhankelijkheden). Bij de toepassing van DI, de objecten gezien hun afhankelijkheden op vormingstijd door een uitwendige entiteit die elk object coördinaten in het systeem. met andere woorden, zijn afhankelijkheden geïnjecteerd voorwerpen."

antwoordde op 22/02/2013 om 15:13
bron van user

stemmen
6

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

Starten eenvoudig en toont codevoorbeelden ook.

voer image beschrijving hier

De consument, X, moet de verbruikte klasse, Y, om iets te bereiken. Dat is allemaal goed en natuurlijk, maar heeft X echt nodig om te weten dat het gebruik maakt van Y?

Is het niet genoeg dat X weet dat het gebruik maakt van iets dat het gedrag heeft, de methoden, eigenschappen etc, van Y zonder te weten wie daadwerkelijk implementeert het gedrag?

Door extractie van een abstracte definitie van het gedrag die door X in Y, weergegeven als I hieronder, en laten de consument dat X een instantie van dat in plaats van Y kan blijven doen wat het doet zonder de details over Y. weten

voer image beschrijving hier

In de bovenstaande afbeelding Y implementeert I en X maakt gebruik van een instantie van I. Hoewel het heel goed mogelijk dat X gebruikt nog steeds Y wat interessant is dat X niet weet dat. Hij weet gewoon dat het iets dat I. implementeert gebruikt

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

  • X is niet afhankelijk Y meer
  • Flexibeler, kan de uitvoering in runtime worden beslist
  • Isolatie van de code-eenheid, gemakkelijker testing

...

antwoordde op 16/02/2017 om 02:03
bron van user

stemmen
4

Inversie van controle over de bediening van de bibliotheek naar de cliënt. Het zinvoller als we het hebben over een cliënt die injecteert (passen) een functiewaarde (lambda expressie) in een hogere orde functie (bibliotheekfunctie) waarmee wordt (verandert) de werking van de bibliotheekfunctie. Een client of raamwerk die bibliotheek afhankelijkheden (welk gedrag dragen) injecteert in bibliotheken kunnen ook worden overwogen IoC

antwoordde op 24/12/2017 om 18:34
bron van user

stemmen
4

Ik vond een zeer duidelijk voorbeeld hier waarin wordt uitgelegd hoe de 'control is omgekeerd'.

Classic code (zonder Dependency injectie)

Hier is hoe een code niet gebruikt DI nagenoeg identiek zal werken:

  • Toepassing moet Foo (bijvoorbeeld een controller), dus:
  • Toepassing maakt Foo
  • Application noemt Foo
    • Foo moet Bar (bijvoorbeeld een dienst), dus:
    • Foo creëert Bar
    • Foo noemt Bar
      • Bar moet Bim (een dienst, een repository, ...), dus:
      • Bar creëert Bim
      • Bar doet iets

Met behulp van dependency injection

Hier is hoe een code met behulp van DI nagenoeg identiek zal werken:

  • Toepassing moet Foo, die Bar nodig heeft, die Bim nodig heeft, dus:
  • Application creëert Bim
  • Toepassing maakt Bar en geeft het Bim
  • Toepassing maakt Foo en geeft het Bar
  • Application noemt Foo
    • Foo noemt Bar
      • Bar doet iets

De besturing van de afhankelijkheden is geïnverteerd van het ene opgeroepen om de ene oproep.

Welke problemen doet het op te lossen?

Dependency injectie maakt het gemakkelijk om te wisselen met de andere implementatie van de geïnjecteerde klassen. Terwijl unit testing kunt u een dummy implementatie, waardoor het testen van een stuk makkelijker maakt te injecteren.

Voorbeeld: Stel dat uw aanvraag van de gebruiker geüploade bestand in de Google Drive, met DI-controller code kan er zo uitzien opslaat:

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 behoeften veranderen zeggen, in plaats van Google Drive wordt u gevraagd naar de Dropbox gebruiken. Je hoeft alleen maar een dropbox implementatie voor de StorageServiceInterface schrijven. Je hoeft niet te maken eventuele wijzigingen in de controller zo lang als Dropbox uitvoering voldoet aan de StorageServiceInterface.

Tijdens het testen kunt u de mock voor de StorageServiceInterface met de dummy implementatie wanneer alle methoden terug te keren null (of een vooraf gedefinieerde waarde als je per testen eis) te creëren.

In plaats daarvan als je moest de controller klasse aan de opslag object met de bouw van newzoekwoord als volgt uit:

class SomeController
{
    private $storage;

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

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

Als u wilt veranderen met de uitvoering Dropbox moet je alle lijnen waar vervangen newGoogleDriveService object is opgebouwd en gebruik de DropboxService. Behalve bij het testen van de SomeController klasse de constructeur verwacht altijd de GoogleDriveService klasse en de werkelijke methoden van deze klasse worden geactiveerd.

Wanneer is het nodig en wanneer niet? Naar mijn mening DI gebruikt u wanneer u denkt dat er (of er kan worden) alternatieve implementaties van een klasse.

antwoordde op 04/11/2017 om 13:27
bron van user

stemmen
4

Ik begrijp dat het antwoord hier al is gegeven. Maar ik denk nog steeds, een aantal basisprincipes over de inversie van controle te hebben om hier te worden besproken in de lengte voor toekomstige lezers.

Inversion of Control (IOC) is gebouwd op een zeer eenvoudig principe genaamd Hollywood Principe . En het zegt dat,

Bel ons niet, wij bellen u

Wat het betekent is dat niet naar de Hollywood om uw droom te vervullen in plaats van als je het waard bent dan Hollywood vindt u en uw droom wordt werkelijkheid zijn. Vrij veel omgekeerd, hè?

Nu wanneer we discussiëren over het principe van de IOC, gebruiken we om te vergeten over de Hollywood. Voor IOC, moet er drie element, een Hollywood, u en een taak graag uw droom te vervullen.

In onze programmering wereld, Hollywood vertegenwoordigen een generiek framework (kan worden geschreven door u of iemand anders), u vertegenwoordigt de gebruiker code hebt geschreven en de opdracht geven de wat je wilt bereiken met uw code. Nu hoef je niet ooit naar je taak te activeren door uzelf, niet in IoC! In plaats daarvan heb je alles in, zodat je framework je taak activeert voor jou zijn ontworpen. Zo heb je een herbruikbare kader dat iemand een held of een ander een schurk kan maken gebouwd. Maar dat kader is altijd de leiding, hij weet wanneer hij moet iemand kiezen en dat iemand alleen weet wat het wil zijn.

Een voorbeeld uit de praktijk zou hier worden gegeven. Stel, je wilt een web-applicatie te ontwikkelen. Dus, een kader dat zal zich bezighouden met alle gewone dingen een webapplicatie moet afhandelen, zoals de behandeling van HTTP-verzoek, het creëren van menu van de toepassing, ten dienste van pagina's, het beheren van cookies, triggering events etc. creëert u

En dan nog wat haken in uw kader laat je waar je verder codes kunt zetten om aangepaste menu's, cookies te genereren of in te loggen enkele gebruiker gebeurtenissen etc. Op elke browser verzoek zal uw kader draaien en voert uw aangepaste codes als dan verslaafd serveren terug naar de browser.

Dus, het idee is vrij veel simpel. In plaats van het creëren van een gebruiksvriendelijke applicatie die alles controleren, eerst creëer je een herbruikbare kader dat alles dan zal de controle te schrijven uw aangepaste codes en haak deze om het kader aan die in de tijd uit te voeren.

Laravel en EJB zijn voorbeelden van dergelijke raamwerken.

Referentie:

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

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

antwoordde op 01/10/2017 om 11:24
bron van user

stemmen
4

IOC is ook bekend als dependency injection (DI). Het is een proces waarbij objecten definiëren hun afhankelijkheden, d.w.z. de andere voorwerpen waarmee zij werken, alleen door constructorargumenten argumenten een fabrieksmethode of eigenschappen die worden vastgesteld op objectexemplaar nadat het is opgebouwd of terug van fabrieksmethode . De container injecteert dan zijn die afhankelijkheden wanneer het de boon creëert. Deze werkwijze is in wezen het omgekeerde, vandaar de naam Inversion of Control (IOC), de boon zelf regelen tot het starten of plaats van de afhankelijkheden door directe constructie van klassen of een mechanisme zoals Leidingzoeker patroon

Spring-framework-referance.pfd pagina 27 (als het tellen van alle pdf document pagina's, is het op pagina 51)

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

antwoordde op 24/01/2013 om 15:52
bron van user

stemmen
3

Inversie van de controle is wanneer je naar de supermarkt en je vrouw geeft u de lijst van producten te kopen.

In programmeertermen gepasseerd ze een callback functie getProductList()om de functie die u uitvoert doShopping();

Het biedt de mogelijkheid van de functie om bepaalde delen te definiëren flexibilisering.

antwoordde op 15/12/2017 om 18:35
bron van user

stemmen
3

Om te begrijpen van het concept, Inversion of Control (IOC) of Dependency Inversion Principle (DIP) bestaat uit twee activiteiten: abstractie, en inversie. Dependency Injection (DI) is slechts een van de weinige van de inversie methoden.

Voor meer informatie over dit leest kun je mijn blog lezen Hier

  1. Wat is het?

Het is een praktijk waar u het feitelijke gedrag van buiten van de grens (Class in Object Oriented Programming) te laten. De grens entiteit kent alleen de abstractie (bv-interface, abstracte klasse, afgevaardigde in Object Oriented Programming) ervan.

  1. Welke problemen doet het op te lossen?

In termen van de programmering, het IOC proberen om monolithische code op te lossen door het maken van it modulaire, ontkoppeling verschillende delen van het, en maak het unit-toetsbaar.

  1. Wanneer is het nodig en wanneer niet?

Het is passend het grootste deel van de tijd, tenzij je situatie waar je gewoon wilt monolithische code (bijvoorbeeld heel eenvoudig programma)

antwoordde op 03/06/2016 om 01:46
bron van user

stemmen
3

Het creëren van een object binnen klasse nauwe koppeling genoemd, Spring verwijdert deze afhankelijkheid door het volgen van een ontwerp patroon (DI / IOC). In die onderwerp van klasse constructor doorgegeven in plaats van het creëren van klasse. Meer dan geven we super klasse referentie variabele in aannemer om meer algemene structuur te definiëren.

antwoordde op 13/05/2015 om 08:52
bron van user

stemmen
3
  1. Dus nummer 1 hierboven . Wat is Inversion of Control?

  2. Onderhoud is de nummer een ding het lost voor mij. Het garandeert Ik gebruik interfaces zodat twee klassen zijn niet intiem met elkaar.

Bij het gebruik van een container, zoals Windsor Castle, het lost onderhoudsproblemen nog beter. In staat zijn om te wisselen van een component die gaat naar een database voor een dat bestand op basis persistentie gebruikt zonder dat een regel code is geweldig (wijziging in de configuratie, je bent klaar).

En zodra je in generieke geneesmiddelen, het wordt nog beter. Stel je voor dat een bericht uitgever die gegevens ontvangt en publiceert berichten. Het maakt niet uit wat het publiceert, maar het moet een mapper iets van een record te nemen aan een bericht.

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

Ik schreef het een keer, maar nu kan ik vele soorten te injecteren in deze set van de code als ik verschillende soorten berichten te publiceren. Ik kan ook schrijven kaartenmakers dat een record van hetzelfde type te nemen en in kaart te brengen om verschillende berichten. Met behulp van DI met Generics heeft mij de mogelijkheid om zeer weinig code om veel taken uit te voeren schrijven gegeven.

Oh ja, er zijn testbaarheid zorgen, maar ze zijn ondergeschikt aan de voordelen van het IOC / DI.

Ik ben zeker liefdevolle IOC / DI.

3. Het wordt beter het moment dat je een middelgrote project van iets meer complexiteit. Ik zou zeggen dat het gepast wordt het moment dat je begint pijn te voelen.

antwoordde op 19/09/2008 om 05:59
bron van user

stemmen
2

Met behulp van IOC u niet new'ing uw objecten. Uw IoC container doet dat en beheren van de levensduur van hen.

Het lost het probleem van het moeten elke instantie van een type object handmatig naar een andere.

Het is geschikt wanneer u functionaliteit die kan veranderen in de toekomst of die verschillend kunnen zijn afhankelijk van de omgeving of configuratie gebruikt in.

antwoordde op 16/07/2015 om 16:06
bron van user

stemmen
1

De allereerste versie van Java EE (J2EE op het moment) introduceerde het concept van de inversie van controle (IOC), wat betekent dat de container controle van uw bedrijf code zou nemen en technische diensten (zoals transactie of security management).

antwoordde op 03/04/2017 om 22:42
bron van user

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