Hva er Inversjon av kontroll?

stemmer
1k

Inversjon of Control (eller IOC) kan være ganske forvirrende når det først oppstått.

  1. Hva er det?
  2. Hvilke problemer løser det?
  3. Når er det riktig og når ikke?
Publisert på 06/08/2008 klokken 03:35
kilden bruker
På andre språk...                            


32 svar

stemmer
1k

Den Inversjon of Control (IOC) og avhengighet injeksjon (DI) mønstre er alle om å fjerne avhengig fra koden.

For eksempel si at programmet har en teksteditor komponent og du ønsker å gi stavekontroll. Din standard kode vil se omtrent slik ut:

public class TextEditor {

    private SpellChecker checker;

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

Hva vi har gjort her skaper en avhengighet mellom TextEditorog SpellChecker. I et IOC scenario ville vi i stedet gjøre noe som dette:

public class TextEditor {

    private IocSpellChecker checker;

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

I det første kodeeksempelet er vi Instantiating SpellChecker( this.checker = new SpellChecker();), som betyr at den TextEditorklassen er direkte avhengig av SpellCheckerklassen.

I det andre kodeeksempelet er vi skape en abstraksjon ved at SpellCheckeravhengigheten klasse i TextEditorkonstruktør signatur (ikke initialisering avhengighet i klasse). Dette gir oss muligheten til å ringe avhengigheten deretter sende den til Texteditor klassen som så:

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

Nå klienten skape TextEditorklassen har kontroll over hvilke SpellCheckerimplementerings å bruke fordi vi injisere avhengigheten til TextEditorsignaturen.

Dette er bare et enkelt eksempel, det er en god serie artikler av Simone Busoli som forklarer det i større detalj.

Svarte 06/08/2008 kl. 07:22
kilden bruker

stemmer
499

Inversjon of Control er hva du får når programtilbakeanrop, for eksempel som et gui program.

For eksempel, i en gammel skole-menyen, kan du ha:

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

for derved å styre strømningen av brukerinteraksjon.

I et GUI program eller somesuch, i stedet sier vi

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

Så nå kontroll er invertert ... i stedet for datamaskinen å akseptere brukerens input i en fast rekkefølge, styrer brukeren rekkefølgen dataene er lagt inn, og når dataene er lagret i databasen.

I utgangspunktet, noe med et arrangement løkke, tilbakeringe, eller utføre utløsere faller i denne kategorien.

Svarte 06/08/2008 kl. 05:42
kilden bruker

stemmer
363

Hva er Inversjon av kontroll?

Hvis du følger disse enkle to trinn, har du gjort inversjon av kontroll:

  1. Separat hva -til-gjøre en del fra når -til-gjøre en del.
  2. Pass på at når en del vet så lite som mulig om hva en del; og vice versa.

Det finnes flere teknikker mulig for hvert av disse trinnene basert på teknologien / språket du bruker for implementeringen.

-

Den inversjon del av inversion of Control (IOC) er det vrient; fordi inversjon er den relativt begrep. Den beste måten å forstå IOC er å glemme det ordet!

-

eksempler

  • Hendelseshåndtering. Hendelseshåndterere (hva-å-gjøre-delen) - øke hendelser (når-å-gjøre-delen)
  • Grensesnitt. Komponent klient (når-å-gjøre-delen) - Component Interface implementering (hva-å-gjøre-delen)
  • xUnit fixure. Oppsett og nedrigging (hva-å-gjøre-delen) - xUnit rammer samtaler til oppsett i begynnelsen og teardown på slutten (da-å-gjøre-delen)
  • Mal metode utforming mønster. mal metoden når å gjøre en del - primitive underklasse gjennomføringen hva å gjøre en del
  • DLL-container fremgangsmåter i COM. DllMain, DllCanUnload, etc (hva-å-gjøre-delen) - COM / OS (når-å-gjøre-delen)
Svarte 22/07/2010 kl. 17:34
kilden bruker

stemmer
95

Inversjon av kontroller er om adskillelse av bekymringer.

Uten IOC : Du har en bærbar datamaskin, og du tilfeldigvis bryte skjermen. Og darn, finner du samme modell laptop-skjermen er intet i markedet. Så du sitter fast.

Med IOC : Du har en stasjonær datamaskin, og du tilfeldigvis bryte skjermen. Du finner du kan bare ta nesten hvilken som helst stasjonær skjerm fra markedet, og det fungerer godt med skrivebordet ditt.

Skrivebordet vellykket implementerer IOC i dette tilfellet. Det aksepterer en rekke type skjermer, mens den bærbare datamaskinen ikke gjør det, trenger den en bestemt skjermen for å bli løst.

Svarte 25/09/2013 kl. 14:24
kilden bruker

stemmer
84

Inversjon of Control, (eller IOC), er i ferd med å få frihet (Du gifte seg, mistet du frihet og du blir kontrollert. Du skilt, har du bare implementert Inversjon of Control. Det er det vi kalte "frakoblet". God datasystem fraråder noen veldig nært forhold.) mer fleksibilitet (kjøkkenet på kontoret bare serverer vannet rent fra springen, er at det eneste valget når du ønsker å drikke. sjefen din implementert Inversjon of Control ved å sette opp en ny kaffemaskin. nå får du fleksibilitet til å velge enten vann fra springen eller kaffe.) og mindre avhengighet (Din partner har en jobb, trenger du ikke har en jobb, du økonomisk avhengige av partneren din, slik at du blir kontrollert. Du finner en jobb, har du implementert Inversjon of Control. God datasystem råder i-avhengighet.)

Når du bruker en stasjonær datamaskin, har du slaved (eller si, kontrollert). Du må sitte foran en skjerm og se på det. Bruke tastaturet til å skrive og bruke musen til å navigere. Og en dårlig skrevet programvare kan være slave deg enda mer. Hvis du erstatter skrivebordet med en laptop, så noe invertert kontroll. Du kan enkelt ta det og flytte rundt. Så nå kan du kontrollere hvor du er med datamaskinen, i stedet for datamaskinen å kontrollere den.

Ved å implementere Inversjon of Control, en software / objekt forbrukeren få flere kontroller / opsjoner i løpet av programvare / objekter, i stedet for å bli kontrollert eller å ha færre alternativer.

Med de ovennevnte ideer i tankene. Vi savner fortsatt en viktig del av IOC. I scenario av IOC, er programvaren / object forbrukeren en sofistikert rammeverk. Det betyr at koden du opprettet ikke kalles selv. Nå la oss forklare hvorfor denne måten fungerer bedre for en web-applikasjon.

Anta at koden er en gruppe av arbeidstakere. De trenger å bygge en bil. Disse arbeiderne trenger et sted og verktøy (en programvare rammeverk) for å bygge bilen. En tradisjonell programvare rammeverk vil være som en garasje med mange verktøy. Så arbeiderne må lage en plan selv og bruke verktøyene til å bygge bilen. Bygge en bil er ikke en enkel virksomhet, vil det være veldig vanskelig for arbeiderne å planlegge og samarbeide riktig. En moderne programvare rammeverk vil være som en moderne bilfabrikk med alle fasiliteter og ledere på plass. Arbeiderne trenger ikke å gjøre noen plan, ledere (del av rammeverket, de er de smarteste menneskene og gjort mest sofistikerte plan) vil bidra til å koordinere slik at arbeiderne vet når de skal gjøre jobben sin (rammeverk kaller koden). Arbeiderne trenger bare å være fleksibel nok til å bruke verktøy ledere gir til dem (ved hjelp Dependency Injection).

Selv om arbeiderne gi kontroll over administrere prosjektet på øverste nivå til ledere (Ramme). Men det er godt å ha noen fagfolk hjelpe. Dette er konseptet med IOC virkelig kommer fra.

Moderne web-applikasjoner med en MVC arkitektur avhenger av rammeverket for å gjøre URL Ruting og sette Controllers på plass for at rammeverk for å ringe.

Avhengighet Injeksjon og Inversjon of Control er relatert. Avhengighet injeksjon er på mikronivå og Inversion of Control er på makronivå. Du må spise hver bit (implementere DI) for å fullføre et måltid (implementere IOC).

Svarte 04/03/2013 kl. 19:33
kilden bruker

stemmer
77

Før du bruker Inversjon of Control bør du være klar over det faktum at det har sine fordeler og ulemper, og du bør vite hvorfor du bruker det hvis du gjør det.

Pros:

  • Koden blir frakoblet slik at du enkelt kan bytte implementeringer av et grensesnitt med alternative implementeringer
  • Det er en sterk motivator for koding mot grensesnitt i stedet for implementeringer
  • Det er veldig lett å skrive enhet tester for koden din fordi det avhenger av noe annet enn de objektene det aksepterer i sin konstruktør / settere og du kan enkelt initial dem med de rette objektene i isolasjon.

Ulemper:

  • IOC ikke bare inverterer kontrollflyt i programmet, det også skyer det betraktelig. Dette betyr at du ikke lenger kan bare lese koden din og hoppe fra ett sted til et annet, fordi tilkoblingene som normalt vil være i koden ikke er i koden lenger. I stedet er det i XML-konfigurasjonsfiler eller merknader og i koden til IOC container som tolker disse metadata.
  • Det oppstår en ny klasse av bugs der du får XML-config eller dine kommentarer galt og du kan bruke mye tid på å finne ut hvorfor IOC container injiserer en null referanse i en av dine objekter under visse betingelser.

Personlig ser jeg den sterke poeng av IOC, og jeg liker dem, men jeg pleier å unngå IOC når det er mulig, fordi det viser programvaren til en samling av klasser som ikke lenger utgjør en "ekte" program, men bare noe som må settes sammen av XML-konfigurasjon eller annotering metadata og ville falle (og faller) fra hverandre uten den.

Svarte 12/02/2010 kl. 14:31
kilden bruker

stemmer
56
  1. Wikipedia-artikkel . For meg er inversjon av kontroll snu sekvensielt bokstav og snu den til en delegasjon struktur. I stedet for programmet eksplisitt kontrollerer alt, setter programmet opp en klasse eller et bibliotek med visse funksjoner som skal kalles når visse ting skje.

  2. Det løser kode duplisering. For eksempel, i gamle dager ville du manuelt skrive ditt eget arrangement loop, polling systembiblioteker for nye hendelser. I dag, de fleste moderne APIer du bare fortelle systembiblioteker hvilke hendelser du er interessert i, og det vil gi deg beskjed når de skjer.

  3. Inversjon av kontroll er en praktisk måte å redusere kode duplisering, og hvis du finner deg selv å kopiere en hel metode og bare endre en liten del av koden, kan du vurdere å takle det med inversjon av kontroll. Inversjon av kontroll gjøres enkelt på mange språk gjennom begrepet delegater, grensesnitt, eller til og med rå funksjonspekere.

    Det er ikke hensiktsmessig å bruke i alle tilfeller, fordi strømmen av et program kan være vanskeligere å følge når skrevet på denne måten. Det er en nyttig måte å utforme metoder når du skriver et bibliotek som vil bli gjenbrukt, men det bør brukes med måte i kjernen av ditt eget program med mindre det virkelig løser en kode duplisering problem.

Svarte 06/08/2008 kl. 04:33
kilden bruker

stemmer
40

Men jeg tror du må være veldig forsiktig med det. Hvis du vil begrense bruken av dette mønsteret, vil du gjøre svært komplisert design og enda mer komplisert kode.

Som i dette eksempelet med Texteditor: hvis du bare har en stavekontroll kanskje det er egentlig ikke nødvendig å bruke IOC? Med mindre du trenger å skrive enhet tester eller noe ...

Uansett: være rimelig. Design mønsteret er god praksis , men ikke Bibelen å bli forkynt. Ikke stikke den overalt.

Svarte 06/08/2008 kl. 22:08
kilden bruker

stemmer
37

Tenk deg at du er et objekt. Og du går til en restaurant:

Uten IOC : du spør etter "eple", og du er alltid servert eple når du spør mer.

Med IOC : Du kan be om "frukt". Du kan få forskjellige frukter hver gang du får servert. for eksempel eple, appelsin, eller vann melon.

Så, åpenbart, er IOC foretrukket når du varianter.

Svarte 25/09/2013 kl. 14:00
kilden bruker

stemmer
35

IOC / DI for meg er å skyve ut avhengigheter til de ringer stedene. Super enkel.

Den ikke-techy svaret er å kunne bytte ut en motor i en bil rett før du slår den på. Hvis alt kroker opp til høyre (grensesnittet), er du god.

Svarte 19/09/2008 kl. 02:54
kilden bruker

stemmer
24
  1. Inversjon av kontroll er et mønster som brukes for frakobling komponenter og lag i systemet. Mønsteret gjennomføres ved injisering av avhengigheter i et komponentrom når det er konstruert. Disse avhengigheter er vanligvis gitt som grensesnitt for ytterligere frakobling og til å støtte testability. IOC / DI beholdere som Castle Windsor, Unity det verktøy (bibliotek) som kan anvendes for å tilveiebringe IOC. Disse verktøyene gir utvidede funksjoner utover enkel avhengighet ledelse, herunder levetid, AOP / Avskjæring, politikk, etc.

  2. en. Lindrer en komponent fra å være ansvarlig for å håndtere det er avhengigheter.
    b. Gir deg muligheten til å bytte avhengighet implementeringer i ulike miljøer.
    c. Lar en komponent bli testet gjennom spottet av avhengigheter.
    d. Gir en mekanisme for å dele ressurser gjennom et program.

  3. en. Kritisk når du gjør testdrevet utvikling. Uten IOC kan det være vanskelig å teste, fordi komponentene under test er sterkt koplet til resten av systemet.
    b. Kritisk ved utvikling av modulsystemer. Et modulsystem er et system hvor bestanddelen kan skiftes ut uten at det kreves recompilation.
    c. Kritisk hvis det er mange tverrgående hensyn som må adresseres, partilarly i et foretak program.

Svarte 19/09/2008 kl. 02:27
kilden bruker

stemmer
19

Jeg skal skrive ned min enkle forståelse av disse to begrepene:

For quick understanding just read examples*

Avhengighet injeksjon (DI):
Avhengighet injeksjon betyr generelt å føre en gjenstand på hvilken metode avhenger, som et parameter til en fremgangsmåte, i stedet for at fremgangsmåten skape den avhengige objektet .
Hva det betyr i praksis er at metoden ikke er direkte på en bestemt gjennomføring; en hvilken som helst implementering som oppfyller kravene kan sendes som en parameter.

Med denne objekter fortelle sine avhengigheter. Og våren gjør det tilgjengelig.
Dette fører til løst koplet programutvikling.

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

Inversjon of Control (IOC) Container:
Dette er felles kjennetegn av rammer, IOC klarer java gjenstander
- fra oppretting til ødeleggelse gjennom sin BeanFactory.
-Java komponenter som startes av IOC beholderen er kalt bønner, og det IOC beholderen styrer en bønne omfang, livssyklus hendelser, og eventuelle AOP funksjoner for hvilke det er blitt konfigurert og kodet.

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.

Ved å implementere Inversjon of Control, en software / objekt forbrukeren få flere kontroller / opsjoner i løpet av programvare / objekter, i stedet for å bli kontrollert eller å ha færre alternativer.

Inversjon av kontroll som en retningslinje utforming har følgende formål:

Det er en frakobling av utføringen av en bestemt oppgave fra gjennomføringen.
Hver modul kan fokusere på det den er konstruert for.
Moduler gjør ingen antagelser om hva andre systemer gjør, men er avhengige av sine kontrakter.
Bytte moduler har ingen bivirkning på andre moduler
jeg vil holde ting abstrakt her, kan du besøke følgende linker for detaljert forståelse av emnet.
En god leser med eksempel

Detaljert forklaring

Svarte 10/11/2014 kl. 08:43
kilden bruker

stemmer
15

Svare bare den første delen. Hva er det?

Inversjon av kontroll (IOC) midler for å skape forekomster av avhengigheter første og siste instans av en klasse (eventuelt injisere dem gjennom konstruktør), i stedet for å opprette en forekomst av klassen først og deretter den klasse forekomst skaper instanser av avhengigheter. Således inversjon av kontroll inverterer den strømmen av kontroll av programmet. I stedet for den anropte å styre den strøm av kontroll (under oppretting av avhengigheter), den styrer anroperen strømmen av kontroll av programmet .

Svarte 11/01/2016 kl. 00:49
kilden bruker

stemmer
15

For eksempel, oppgave # 1 er å opprette objekt. Uten IOC-konseptet, er oppgave # 1 skal gjøres av Programmer.But Med IOC-konseptet, ville oppgaven # 1 gjøres av beholderen.

I korte Kontroll blir invertert fra programmereren til beholderen. Så, kalles det som inversjon av kontroll.

Jeg fant et godt eksempel her .

Svarte 27/01/2010 kl. 12:15
kilden bruker

stemmer
14

Det virker som det mest forvirrende ting om "IOC" akronym og navnet som det står er at det er altfor glamorøse av et navn - nesten en støy navn.

Har vi virkelig trenger et navn ved å beskrive forskjellen mellom prosessuelle og hendelsesdrevet programmering? OK, hvis vi må, men trenger vi å plukke en splitter ny "større enn livet" navn som forvirrer mer enn det løser?

Svarte 19/01/2011 kl. 03:50
kilden bruker

stemmer
14

Jeg er enig med NilObject , men jeg vil gjerne legge til dette:

Hvis du finner deg selv å kopiere en hel metode og bare endre en liten del av koden, kan du vurdere å takle det med inversjon av kontroll

Hvis du finner deg selv å kopiere og lime inn kode rundt, er du nesten alltid gjør noe galt. Kodifisert som design prinsipp gang og bare én gang .

Svarte 06/08/2008 kl. 05:20
kilden bruker

stemmer
13

La oss si at vi gjør noen møtet i enkelte hotell.

Mange, mange karaffel med vann, mange plastkopper.

Når noen ønsker å drikke, hun fyller cup, drikke og kaste cup på gulvet.

Etter time eller noe har vi et gulv dekket av plast kopper og vann.

La invert kontroll.

Samme møte på samme sted, men i stedet for plastkopper vi har et Kelner med en glassbeger (Singleton)

og hun hele tiden tilbud til gjester som drikker.

Når noen ønsker å drikke, hun får fra servitør glass, drikke og returnere den tilbake til servitør.

Når vi ser bort spørsmålet om hygienisk, siste formen for drikking prosesskontroll er mye mer effektivt og økonomisk.

Og dette er akkurat hva våren (en annen IOC container, for eksempel: Guice) gjør. I stedet for å la påføring lage hva det trenger å bruke nye søkeord (tar plastkopp), Spring IOC container hele tiden tilbud til søknaden samme instans (enkelt) av nødvendig objekt (glass vann).

Tenk på deg selv som arrangør av møtet. Du må helt til melding til hotellet administrasjon som

møte medlemmer vil trenge glass vann, men ikke del av kaken.

Eksempel:-

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

}

Nyttige lenker:-

Svarte 26/09/2012 kl. 17:54
kilden bruker

stemmer
10

IOC om å snu forholdet mellom kode og tredjepartskode (bibliotek / ramme):

  • I normale s / w utvikling, skriver du main () metoden og kaller "bibliotek" metoder. Du er i kontroll :)
  • I IOC den "rammen" styrer main () og kaller dine metoder. Den Ramme er i kontroll :(

DI (avhengighet injeksjon) er om hvordan styre flyter i søknaden. Tradisjonelle desktop-programmet hadde kontrollflyt fra programmet (main () -metoden) til andre bibliotek metodekall, men med DI kontrollflyt er snudd det er rammen tar seg av å starte din app, initialisere den og påkalle dine metoder når nødvendig.

I slutten du alltid vinne :)

Svarte 19/09/2014 kl. 18:25
kilden bruker

stemmer
7

Inversjon av kontroll er når du går til butikken og din kone gir deg en liste over produkter å kjøpe.

I programmerings vilkår passert hun en tilbakeringingsfunksjonen getProductList()til funksjonen du utfører doShopping();

Det tillater brukeren av funksjon for å definere noen deler av det slik at det er mer fleksibel.

Svarte 15/12/2017 kl. 18:35
kilden bruker

stemmer
7

Jeg fant et veldig klart eksempel her som forklarer hvordan 'kontroll er invertert'.

Klassisk nummer (uten Avhengighet injeksjon)

Her er hvordan en kode som ikke bruker DI vil omtrent fungere:

  • Program krever Foo (for eksempel en styringsenhet), slik at:
  • Søknad skaper Foo
  • Søknad kaller Foo
    • Foo må Bar (f.eks en tjeneste), så:
    • Foo skaper Bar
    • Foo kaller Bar
      • Bar trenger Bim (en tjeneste, et oppbevaringssted, ...), så:
      • Bar skaper Bim
      • Bar gjør noe

Bruke avhengighet injeksjon

Her er hvordan en kode ved hjelp av DI vil omtrent fungere:

  • Søknad må Foo, som må Bar, som trenger Bim, så:
  • Søknad skaper Bim
  • Søknad skaper Bar og gir den Bim
  • Søknad skaper Foo og gir den Bar
  • Søknad kaller Foo
    • Foo kaller Bar
      • Bar gjør noe

Kontroll av avhengigheter er invertert fra en blir kalt til en kall.

Hvilke problemer løser det?

Avhengighet injeksjon gjør det enkelt å bytte med de forskjellige gjennomføringen av injisert klasser. Mens enhetstesting kan du injiserer en dummy implementering, noe som gjør testing mye enklere.

Ex: Anta at programmet lagrer bruker lastet opp filen i Google Disk, med DI kontrolleren kode kan se slik ut:

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

Når behovene endres si, i stedet for Google Drive du blir bedt om å bruke Dropbox. Du trenger bare å skrive en dropbox implementering for StorageServiceInterface. Du trenger ikke gjøre noen endringer i styringen så lenge Dropbox gjennomføring fester seg til StorageServiceInterface.

Mens testing kan du opprette mock for StorageServiceInterface med dummy gjennomføring der alle metodene returnerer null (eller en forhåndsdefinert verdi som per testing krav).

I stedet hvis du hadde kontrolleren klassen å konstruere lagringsobjekt med newsøkeord som dette:

class SomeController
{
    private $storage;

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

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

Når du ønsker å endre med Dropbox gjennomføringen du må erstatte alle linjene der newGoogleDriveService objektet er konstruert og bruke DropboxService. I tillegg når du tester SomeController klassen konstruktør alltid forventer GoogleDriveService klasse og den faktiske metoder i denne klassen er utløst.

Når er det riktig og når ikke? Etter min mening kan du bruke DI når du tror det er (eller det kan være) alternative implementeringer av en klasse.

Svarte 04/11/2017 kl. 13:27
kilden bruker

stemmer
7

Jeg liker denne forklaringen: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Det starter enkelt, og viser kode eksempler også.

skriv bildebeskrivelse her

Forbrukeren, X, må forbrukes klassen, Y, for å oppnå noe. Det er alt godt og naturlig, men ikke X virkelig trenger å vite at den bruker Y?

Er det ikke nok at X vet at den bruker noe som har atferd, metoder, egenskaper osv, Y uten å vite hvem som faktisk implementerer atferd?

Ved å trekke ut en abstrakt definisjon av virkemåten som brukes ved X i Y, som illustrert i det følgende, og å la forbrukeren X benytte en forekomst av at i stedet for Y kan det fortsette å gjøre det den gjør uten å vite detaljer om Y.

skriv bildebeskrivelse her

I illustrasjonen ovenfor Y implementerer jeg og X bruker en forekomst av I. Selv om det er fullt mulig at X fortsatt bruker Y hva som er interessant er at X ikke vet det. Det vet bare at den bruker noe som implementerer I.

Les artikkelen for ytterligere info og beskrivelse av fordeler som:

  • X er ikke avhengig av Y lenger
  • Mer fleksibel, kan gjennomføringen bli avgjort i runtime
  • Isolering av kodeenheten, enklere testing

...

Svarte 16/02/2017 kl. 02:03
kilden bruker

stemmer
7

Inversjon av kontroll er en generisk prinsipp, mens avhengighet injeksjon innser dette prinsipp som et designmønster for objektet graf anleggs (dvs. konfigurasjonskontroller hvordan objektene er refererer hverandre, snarere enn selve objektet som styrer hvordan man kan få referanse til et annet objekt).

Ser på Inversjon of Control som et design mønster, må vi se på hva vi snu. Avhengighet injeksjon inverterer kontroll for å konstruere en graf av objekter. Hvis fortalt i lekmann sikt, inversjon av kontroll innebærer endring i flyten av kontroll i programmet. Eg. I tradisjonell frittstående applikasjon, har vi viktigste metoden, hvor kontrollen blir overført til andre tredjeparts biblioteker (i tilfelle, har vi brukt tredjepart bibliotekets funksjon), men gjennom inversjon av kontroll kontroll blir overført fra tredjepart bibliotek kode til vår kode , som vi tar service av tredjeparts bibliotek. Men det er andre aspekter som må inverteres i løpet av et program - f.eks påkalling av metoder og tråder for å kjøre koden.

For de som er interessert i mer dybde på Inversjon of Control et papir har blitt publisert som beskriver et mer fullstendig bilde av Inversjon of Control som et designmønster (OfficeFloor: ved hjelp av kontor mønstre for å forbedre software design http://doi.acm.org/10.1145/ 2739011.2739013 med en gratis kopi tilgjengelig for nedlasting fra http://www.officefloor.net/mission.html )

Hva er identifisert er følgende forhold:

Inversjon av kontroll (for metoder) = Avhengighet (tilstand): Injeksjon + Videreføring Injiserbare + tråden Injiserbare

Svarte 29/10/2015 kl. 04:27
kilden bruker

stemmer
7

programmering taler

IOC i enkle betingelser: Det er bruk av grensesnitt som en måte bestemt noe (for eksempel et felt eller en parameter) som joker som kan brukes av noen klasser. Det gjør at gjenbrukbarheten av koden.

For eksempel, la oss si at vi har to klasser: Dog og Cat . Begge deler de samme kvalitetene / sier: alder, størrelse, vekt. Så i stedet for å opprette en serviceklassen heter DogService og CatService , kan jeg lage en eneste en som heter AnimalService som gjør det mulig å bruke hund og katt bare hvis de bruker grensesnittet IAnimal .

Men pragmatisk sett, har det noen baklengs.

a) De fleste av utviklerne ikke vet hvordan den skal brukes . For eksempel kan jeg lage en klasse kalt Kunde og jeg kan lage automatisk (ved hjelp av verktøyene i IDE) et grensesnitt som kalles ICustomer . Så det er ikke sjelden å finne en mappe fylt med klasser og grensesnitt, uansett om grensesnittene vil bli gjenbrukt eller ikke. Det kalles oppsvulmet. Noen mennesker kan argumentere for at "kan være i fremtiden vil vi kunne bruke det". : - |

b) Den har noen begrensninger,. For eksempel, la oss snakke om det gjelder hund og katt , og jeg vil legge til en ny tjeneste (funksjonalitet) bare for hunder. La oss si at jeg ønsker å beregne antall dager som jeg trenger å trene en hund ( trainDays()), for katten det er ubrukelig, katter kan ikke trenes (jeg fleiper).

b.1) Hvis jeg legger trainDays()til Tjenesten AnimalService så det fungerer også med katter og det er ikke gyldig i det hele tatt.

b.2) Jeg kan legge til en tilstand trainDays()hvor det evalueres som klasse er brukt. Men det vil bryte helt IOC.

B.3) Jeg kan lage en ny klasse av tjeneste kalt DogService bare for ny funksjonalitet. Men, vil det øke vedlikehold av koden, fordi vi vil ha to klasser av tjenesten (med tilsvarende funksjonalitet) for hunden , og det er ille.

Svarte 19/04/2015 kl. 12:07
kilden bruker

stemmer
7

En veldig enkel skriftlig forklaring finner du her

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

det står

"Enhver nontrivial programmet består av to eller flere klasser som samarbeider med hverandre for å utføre noen forretningslogikk. Tradisjonelt er hvert objekt ansvarlig for å skaffe sine egne referanser til objektene det samarbeider med (dens avhengigheter). Ved søknad DI, den gjenstander er gitt deres avhengigheter ved opprettelse tid av noen eksterne entiteten som koordinerer hvert objekt i systemet. med andre ord, blir avhengig injisert inn objekter ".

Svarte 22/02/2013 kl. 14:13
kilden bruker

stemmer
4

Inversjon av kontroll er om overføring av styring fra biblioteket til klienten. Det er mer fornuftig når vi snakker om en klient som injiserer (passerer) en funksjonsverdi (lambda uttrykk) i en høyere ordens funksjon (biblioteksfunksjon), som styrer (endring) oppførselen til bibliotek funksjon. En klient eller rammeverk som injiserer bibliotekavhengigheter (som bærer oppførsel) inn i biblioteker kan også bli betraktet som IOC

Svarte 24/12/2017 kl. 18:34
kilden bruker

stemmer
4

Jeg forstår at svaret allerede er gitt her. Men jeg tror fremdeles noen grunnleggende om inversjon av kontroll må bli diskutert her i lengde for fremtidige lesere.

Inversjon of Control (IOC) har blitt bygget på en svært enkelt prinsipp kalt Hollywood-prinsippet . Og det står det,

Ikke ring oss, vi ringer deg

Hva det betyr er at ikke gå til Hollywood for å oppfylle drømmen heller om du er verdig da Hollywood vil finne deg og gjøre drømmen blir virkelighet. Ganske mye invertert, ikke sant?

Nå når vi diskuterer om prinsippet om IOC, bruker vi å glemme om Hollywood. For IOC, det må være tre element, en Hollywood, du og en oppgave å oppfylle din drøm.

I vår programmering verden, Hollywood representerer et generisk rammeverk (kan være skrevet av deg eller noen andre), du representerer brukerkoden du skrev og oppgaven representerer ting du ønsker å oppnå med koden din. Nå trenger du ikke noen gang gå å utløse din oppgave selv, ikke i IOC! Heller du har designet alt slik at rammen vil utløse din oppgave for deg. Dermed har du bygget en gjenbrukbar rammeverk som kan gjøre noen en helt eller en annen en skurk. Men dette rammeverket er alltid ansvarlig, det vet når å plukke noen og at noen vet hva den ønsker å være.

En ekte liv eksempel ville bli gitt her. Anta at du ønsker å utvikle en webapplikasjon. Så lager du et rammeverk som vil håndtere alle de vanlige tingene en webapplikasjon bør håndtere som håndterer http forespørsel, lage programmenyen serverer sider, administrerende cookies, utløser hendelser etc.

Og så la noen kroker i din rammeverk hvor du kan sette ytterligere koder for å generere egendefinerte meny, sider, informasjonskapsler eller logge noen brukerhendelser etc. På hver leseren forespørsel, vil ramme kjøre og utfører dine egne koder hvis hektet deretter tjene det tilbake til nettleseren.

Så, ideen er ganske mye enkel. Snarere enn å lage et brukerprogram som vil kontrollere alt, først oppretter du en gjenbrukbar rammeverk som skal styre alt og deretter skrive dine egne koder og koble den til rammeverk for å utføre de i gang.

Laravel og EJB er eksempler på slikt rammeverk.

Henvisning:

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

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

Svarte 01/10/2017 kl. 11:24
kilden bruker

stemmer
4

IOC er også kjent som avhengighet injeksjon (DI). Det er en prosess hvorved gjenstander definere deres avhengigheter, det vil si, de andre objektene de arbeider med, bare gjennom konstruktør argumenter, argumenter til en fabrikk metode, eller egenskaper som er satt på objektet forekomsten etter at den er konstruert eller returneres fra en fabrikk metode . Beholderen injiserer så disse avhengigheter når det skaper bønne. Denne prosessen er fundamentalt den inverse, derav navnet inversion of Control (IOC), av bønnene selv å styre den eller plassering av dens avhengigheter ved hjelp av direkte konstruksjon av klassene, eller en mekanisme, slik som tjeneste Locator mønster

Spring-rammeverket-referance.pfd side 27 (hvis telle alle pdf dokumentsider, er det på side 51)

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

Svarte 24/01/2013 kl. 15:52
kilden bruker

stemmer
3

For å forstå konseptet, Inversjon of Control (IOC) eller Dependency Inversion Principle (DIP) involverer to aktiviteter: abstraksjon, og inversjon. Avhengighet injeksjon (DI) er bare en av de få av de inversjonsmetoder.

For å lese mer om dette kan du lese bloggen min her

  1. Hva er det?

Det er en praksis der du la den faktiske atferden kommer fra utsiden av grensen (klasse i objektorientert programmering). Grensen enhet bare kjenner abstraksjon (f.eks grensesnitt, abstrakt klasse, delegat i objektorientert programmering) av det.

  1. Hvilke problemer løser det?

På sikt av programmering, IOC prøve å løse monolittisk kode ved å gjøre det modulære, decoupling ulike deler av det, og gjøre det unit-testbar.

  1. Når er det riktig og når ikke?

Det er hensiktsmessig mesteparten av tiden, med mindre du har situasjon hvor du bare ønsker monolittisk kode (f.eks veldig enkelt program)

Svarte 03/06/2016 kl. 01:46
kilden bruker

stemmer
3

Oppretting av et objekt innenfor klasse som kalles tett kopling, fjerner Spring denne avhengigheten ved å følge et mønster konstruksjon (DI / IOC). I hvilken i pass objekt av klassen i konstruktør stedet for å skape i klassen. Mer over gir vi super klasse referanse variabel i konstruktør å definere mer generell struktur.

Svarte 13/05/2015 kl. 08:52
kilden bruker

stemmer
3
  1. Så nummer 1 ovenfor . Hva er Inversjon av kontroll?

  2. Vedlikehold er nummer én ting det løser for meg. Det garanterer jeg bruker grensesnitt, slik at to klasser er ikke intime med hverandre.

Ved bruk av en beholder som Castle Windsor, løser det vedlikehold problemer enda bedre. Å kunne bytte ut en komponent som går til en database for en som bruker fil basert utholdenhet uten å endre en linje med kode er kjempebra (konfigurasjonsendring, er du ferdig).

Og når du kommer inn generics, blir det enda bedre. Tenk å ha en melding utgiver som mottar poster og publiserer meldinger. Den bryr seg ikke hva det utgir, men det er behov for en mapper for å ta noe fra en post til en melding.

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

Jeg skrev det en gang, men nå kan jeg injisere mange typer i dette settet av kode hvis jeg publisere ulike typer meldinger. Jeg kan også skrive kartleggere som tar en registrering av samme type og kart dem til ulike meldinger. Bruke DI med Generics har gitt meg muligheten til å skrive svært lite kode for å utføre mange oppgaver.

Oh yeah, det er testbarhet bekymringer, men de er sekundært til fordelene av IOC / DI.

Jeg er definitivt kjærlig IOC / DI.

3. Det blir mer aktuelt i det øyeblikk du har en mellomstor prosjekt av noe mer kompleksitet. Jeg vil si det blir aktuelt i det øyeblikk du begynner å føle smerte.

Svarte 19/09/2008 kl. 04:59
kilden bruker

stemmer
2

Ved hjelp av IOC du ikke new'ing opp gjenstander. Din IOC container vil gjøre det og administrere levetiden av dem.

Det løser problemet med å måtte endre hver oppretting av en type objekt manuelt til en annen.

Det er hensiktsmessig når du har funksjonalitet som kan endre seg i fremtiden, eller som kan være forskjellig avhengig av miljøet eller konfigurasjon brukes i.

Svarte 16/07/2015 kl. 16:06
kilden bruker

stemmer
1

Den aller første versjonen av Java EE (J2EE på den tiden) introduserte begrepet inversjon av kontroll (IOC), som betyr at beholderen ville ta kontroll over din virksomhet koden og gi tekniske tjenester (for eksempel transaksjon eller sikkerhetsadministrasjon).

Svarte 03/04/2017 kl. 22:42
kilden bruker

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