Mi Inversion of Control?

szavazat
1k

Inversion of Control (vagy NOB) is elég zavaró, amikor először találkozott.

  1. Mi az?
  2. Milyen problémákat old meg?
  3. Mikor helyénvaló és mikor nem?
A kérdést 06/08/2008 04:35
a forrás felhasználó
Más nyelveken...                            


38 válasz

szavazat
1k

Az Inversion of Control (NOB) és függőség befecskendezésű (DI) minták minden eltávolításával függőségek kódot.

Tegyük fel például, az alkalmazás egy szövegszerkesztő komponens, és szeretné, hogy a helyesírás-ellenőrzőt. A szabványos kód a következőképpen néz ki:

public class TextEditor {

    private SpellChecker checker;

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

Mit tettünk itt létrehoz egy függőség között TextEditor, és a SpellChecker. Egy NOB forgatókönyv mi lenne helyette valami hasonlót:

public class TextEditor {

    private IocSpellChecker checker;

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

Az első példakódban vagyunk példányosítanánk SpellChecker( this.checker = new SpellChecker();), ami azt jelenti, az TextEditorosztály közvetlenül függ az SpellCheckerosztályban.

A második kód például hozunk létre egy absztrakció azáltal, hogy a SpellCheckerfüggőség osztály TextEditorkonstruktor aláírás (nem inicializálása függőségi osztály). Ez lehetővé teszi számunkra, hogy hívja a függőség, majd átadja azt az TextEditor osztály valahogy így:

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

Most az ügyfél létrehozásának TextEditorosztálynak megvan az ellenőrzése alatt, amely SpellCheckervégrehajtásának használni, mert mi befecskendezésével függőség az TextEditoraláírást.

Ez csak egy egyszerű példa, van egy jó cikksorozat Simone Busoli ez megmagyarázza részletesebben.

Válaszolt 06/08/2008 08:22
a forrás felhasználó

szavazat
485

Inversion of Control, amit kapsz, ha a programot visszahívások, például mint egy gui programot.

Például egy régi iskolában menü, lehet, hogy:

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

ezáltal szabályozza az áramlás a felhasználói beavatkozás.

A GUI program vagy somesuch helyett azt mondjuk,

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

Tehát most a fordított ... ahelyett, hogy a számítógép elfogadó felhasználói meghatározott sorrendben, a felhasználó vezérli a sorrendet, amelyben az adatok bevitele, és ha az adatok mentésre kerülnek az adatbázisban.

Alapvetően semmit esemény hurok, visszahívások, vagy végre kiváltó ebbe a kategóriába esik.

Válaszolt 06/08/2008 06:42
a forrás felhasználó

szavazat
356

Mi Inversion of Control?

Ha követed ezeket az egyszerű két lépésben tettél a kontroll megfordítása:

  1. Külön mi to-do részben , amikor to-do része.
  2. Biztosítani kell, hogy amikor részt tud a kis kezdő lehetséges , mi része; és fordítva.

Többféle módszerrel lehetséges az egyes lépések technológián alapuló / nyelvet használ a végrehajtás.

-

A inverziós része a kontroll megfordítása (NOB) van a zavaró dolog; mert inverzió a relatív kifejezés. A legjobb módja annak, hogy megértsük NOB, hogy felejtse el ezt a szót!

-

Példák

  • Események kezelésére. Eseménykezelők (mit-do rész) - A figyelem események (ha-to-do rész)
  • Interfészek. Component kliens (ha-to-do rész) - Component Interface végrehajtás (mit-do rész)
  • xUnit fixure. Felépítése és bontása (mit-do rész) - xUnit keretek kéri a telepítő elején és bontása a végén (ha-to-do rész)
  • Sablon módszer tervezési minta. sablon módszer, ha to-do rész - primitív alosztály végrehajtás mit-nem választ
  • DLL tartályt módszerek COM. DllMain, DllCanUnload stb (mit-do rész) - COM / OS (ha-to-do rész)
Válaszolt 22/07/2010 18:34
a forrás felhasználó

szavazat
81

Inversion kontrollok mintegy elválasztó aggályokat.

Anélkül NOB : Van egy laptop számítógépet, és véletlenül megtörni a képernyőn. És rohadt, megtalálni ugyanazt a modellt laptop képernyőjén nincs a piacon. Így ragadtunk.

NOB : Van egy asztali számítógépet és véletlenül megtörni a képernyőn. Találsz akkor csak megragad szinte bármilyen asztali monitor a piacon, és ez jól működik az asztalon.

Az asztali sikeresen valósítja NOB ebben az esetben. Elfogadja a különböző típusú monitorok, míg a laptop nem, akkor szüksége van egy képernyő, hogy fix.

Válaszolt 25/09/2013 15:24
a forrás felhasználó

szavazat
77

Inversion of Control (vagy NOB), körülbelül szerzés szabadság (Te férjhez, akkor elvesztette szabadságát, és azért mutatott. Azt elvált, éppen most végre Inversion of Control. Ez az, amit az úgynevezett „függetlenített”. Jó számítógépes rendszer visszatartja néhány nagyon szoros összefüggés van.) nagyobb rugalmasság (a konyha az irodában csak arra szolgál, tiszta csapvízzel, hogy az egyetlen választás, ha azt szeretné, hogy igyon. a főnök végre Inversion of Control létrehozásával egy új kávéfőző. most kap a rugalmasság eldönthessék csapvíz vagy kávé.), és kevésbé függünk (a partnere egy munkát, akkor nem kell a munkát, akkor anyagilag függ a partner, így elpusztulnak. a munkát találni, akkor végre megfordítása Ellenőrzési. Jó számítógépes rendszer arra ösztönzi a függőséget.)

Ha olyan asztali számítógépet, akkor alárendelt (vagy mondjuk, szabályozható). Meg kell ülni, mielőtt a képernyőt, és nézd meg. A billentyűzet segítségével, és az egérrel navigálni. És egy rosszul megírt szoftver szolga még. Ha kicseréli az asztalon egy laptop, akkor némileg fordított ellenőrzés. Könnyedén veszi azt, és mozogni. Így most már tudod irányítani, hogy hol van a számítógéppel, ahelyett, hogy a számítógép vezérlésére is.

A végrehajtó Inversion of Control, egy szoftver / tárgy fogyasztó minél több ellenőrzés / beállítások alatt a szoftver / tárgyak, ahelyett, hogy az ellenőrzött vagy amelynek kevesebb lehetőség.

A fenti gondolatok szem előtt. Még mindig hiányzik egy kulcsfontosságú része a NOB. A forgatókönyv a NOB, a szoftver / tárgy fogyasztó egy kifinomult keret. Ez azt jelenti, hogy a kód létre nem hívják egyedül. Most miért így jobban működik egy webes alkalmazás.

Tegyük fel, hogy a kód egy munkavállalói csoport. Meg kell építeni egy autót. Ezek a dolgozók kell egy hely és eszközök (a szoftver keretrendszer) építeni az autót. A hagyományos program keretén lesz, mint egy garázs számos eszközt. Így aztán a munkások kell, hogy a terv magukat, és használja az eszközöket építeni az autót. Épület egy autó nem könnyű vállalkozás, akkor nagyon nehéz a munkások tervezni és együttműködni megfelelően. A modern szoftver keretrendszer lesz, mint egy modern autó gyári minden eszközt és a vezetők a helyükön. A dolgozók nem kell semmilyen tervet, a vezetők (a keret része, ők a legokosabb emberek, és tette a legkifinomultabb terv) segít koordinálni, hogy a dolgozók tudják, hogy mikor kell ezt a munkát (keret kéri a kódot). A munkások csak rugalmasnak kell lenniük ahhoz, hogy ne használjon semmilyen szerszámot a vezetők adni nekik (az a függőség injekció).

Bár a gondozók ellenőrzése a projekt irányítása a legfelső szinten a vezetők (a keret). De jó, hogy van néhány szakember segíteni. Ez a koncepció a NOB valóban származik.

Modern webalkalmazások egy MVC architektúra függ keretet tenni URL Routing és tegye vezérlők érvényben keretében hívja.

Függőség Injekció és Inversion of Control kapcsolódik. Függőség befecskendezés a mikro szinten Inversion of Control áll a makro szinten. Meg kell enni minden falat (végre DI), annak érdekében, hogy befejezze az étkezés (végre NOB).

Válaszolt 04/03/2013 20:33
a forrás felhasználó

szavazat
72

Használat előtt Inversion of Control meg kell jól ismeri a tényt, hogy megvan a maga előnye és hátránya, és meg kell tudni, hogy miért használja azt, ha nem így van.

Előnyök:

  • A kód kerül függetlenített így könnyen cserélnek megvalósításai interfész alternatív megvalósítások
  • Ez egy erős motiváló kódolási ellen felületek helyett megvalósítások
  • Ez nagyon egyszerű, hogy írjon egység vizsgálatok a kódot, mert ez attól függ, nem más, mint a tárgyakat, hogy elfogadja saját kivitelező / alkotói és könnyen inicializálni őket a megfelelő objektumokat elszigetelten.

Hátrányok:

  • NOB nem csak megfordítja az ellenőrzés folyamatát a programot, akkor is elhomályosítja, akkor jelentősen. Ez azt jelenti, hogy már nem csak olvasni a kódot, és ugrik az egyik helyről a másikra, mert a kapcsolat, ami általában a kódban nem a kód már. Ehelyett ez az XML konfigurációs fájlokat és a jelölések és a kódját NOB tartály, amely értelmezi ezeket a metaadatokat.
  • Felmerül egy új osztályt a hibákat, ahová az XML konfigurációs vagy kommentárokat rossz, és meg lehet tölteni egy csomó időt találni arra, hogy miért a NOB konténer fecskendez a null referencia, az egyik a tárgyak bizonyos feltételek mellett.

Személyesen látom erősségei NOB és én nagyon szeretem őket, de én inkább elkerülni NOB amikor csak lehetséges, mert kiderül a szoftver egy gyűjtemény osztályok, amelyek már nem minősülnek „igazi” programot, de csak valami, amit meg kell tenni össze XML konfigurációs vagy jegyzet metaadatok és esne (és esik) egymástól nélkül.

Válaszolt 12/02/2010 15:31
a forrás felhasználó

szavazat
55
  1. Wikipedia cikk . Számomra a kontroll megfordítása fordul meg egymás után írt kódot, és fordult be egy küldöttség szerkezetét. Ahelyett, hogy a program kifejezetten kontrolling mindent, a programot hoz létre egy osztály vagy könyvtár bizonyos funkciók hívják, ha bizonyos dolgok történnek.

  2. Ez megoldja párhuzamos kódot. Például a régi időkben kézzel azt írni a saját esemény hurok lekérdezési rendszer könyvtárak új események. Manapság a legtöbb modern API egyszerűen elmondani a rendszer könyvtárak milyen események Önt érdeklő, és tudatja Önnel, amikor történik.

  3. Inversion ellenőrzés egy praktikus módja annak, hogy csökkentsék párhuzamos kódot, és ha talál magának másol egy egész eljárást és csak a kis darab a kódot, akkor úgy leküzdése azt a kontroll megfordítása. Inversion ellenőrzési készült könnyű sok nyelven fogalmán keresztül küldött, interfészek, vagy akár nyers függvénymutatók.

    Ez nem megfelelő használata minden esetben, mert a folyam egy program lehet nehezebb követni, ha írásos ezen a módon. Ez egy hasznos módja a tervezési módszerek írásakor könyvtár lesz újra, de takarékosan kell használni a lényege saját programot, kivéve, ha valóban megoldja a problémát párhuzamos kódot.

Válaszolt 06/08/2008 05:33
a forrás felhasználó

szavazat
38

De azt hiszem, meg kell hogy legyen nagyon óvatos vele. Ha majd túlzásba ezt a mintát, akkor hogy nagyon bonyolult, és még bonyolultabb kódot.

Mint ebben a példában TextEditor: ha csak egy SpellChecker talán ez nem igazán kell használni NOB? Kivéve, ha kell írni unit tesztek, vagy valami ...

Egyébként: ésszerűnek. Tervezési minták vannak a jó gyakorlatok , de nem Biblia, prédikált. Ne helyezze mindenhol.

Válaszolt 06/08/2008 23:08
a forrás felhasználó

szavazat
34

Tegyük fel, hogy egy tárgy. És elmész egy étterembe:

Anélkül NOB : kérsz „alma”, és akkor mindig szolgálnak alma, ha kéred tovább.

NOB : Kérhet „gyümölcs”. Lehet kapni különböző gyümölcsök minden alkalommal kap szolgált. például alma, narancs, vagy víz dinnye.

Tehát nyilvánvaló, hogy NOB előnyös, ha úgy tetszik, a fajták.

Válaszolt 25/09/2013 15:00
a forrás felhasználó

szavazat
34

NOB / DI nekem törekszik arra, függőségek a hívó tárgyakat. Szuper egyszerű.

A nem-ingerlékeny válasz az, hogy képes cseréld le a motor az autóban, mielőtt bekapcsolja. Ha minden horgok fel jobbra (a felület), akkor jó.

Válaszolt 19/09/2008 03:54
a forrás felhasználó

szavazat
23
  1. A kontroll megfordítása egy minta használt függetlenítés komponensek és a rétegek a rendszerben. A minta keresztül hajtják végre intravénás függőségeket egy komponensre, ha azt megépíteni. Ezek függőségek általában olyan, mint interfész további szétválasztásra és támogassa tesztelhetőségi. NOB / DI tartályok, mint a Castle Windsor, Unity eszközei (könyvtárak), amelyet fel lehet használni a biztosító NOB. Ezek az eszközök kiterjesztett funkciók felett és azon túl egyszerű függőség kezelése, beleértve az élettartam, AOP / lehallgatás, politika, stb

  2. a. Enyhíti egy alkatrészt, hogy kezeléséért felelős ez a függőségeket.
    b. Lehetővé teszi, hogy a csere függőség megvalósítások különböző környezetekben.
    c. Lehetővé teszi egy komponenst kell tesztelni révén főbűnét függőségek.
    d. Mechanizmust biztosít az erőforrások megosztása az egész egy alkalmazást.

  3. a. Kritikus amikor egy teszt-vezérelt fejlesztés. Anélkül NOB nehéz lehet tesztelni, mert az összetevők vizsgálat alatt erősen kapcsolódik a rendszer többi részéhez.
    b. Kritikus fejlesztése során moduláris rendszer. A moduláris rendszer egy olyan rendszer, amelynek elemei lehet cserélni anélkül, hogy újrafordítás.
    c. Kritikus ha sok horizontális aggályok kell foglalkozni, partilarly vállalati alkalmazás.

Válaszolt 19/09/2008 03:27
a forrás felhasználó

szavazat
17

Azt kell leírni az én egyszerű megérteni ezt a két fogalmat:

For quick understanding just read examples*

Függőségi Injection (DI):
függőség injekció általában azt jelenti, halad egy tárgy, amelyen módszer függ, mint a paraméter a módszer, ahelyett, az eljárás létrehozása a függő objektumot .
Mit jelent ez a gyakorlatban, hogy az eljárás nem közvetlenül függ az adott végrehajtását; minden olyan alkalmazás megfelel a átadhatók paraméterként.

Ezzel a tárgyak mondani Thier függőségeket. És tavasszal elérhetővé teszi.
Ez vezet a lazán csatolt alkalmazások fejlesztését.

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

A kontroll megfordítása (NOB) Konténer:
Ez közös jellemzője a keretek, NOB felszabadítással Java objektumok
- a példányosítását pusztulásra keresztül BeanFactory.
-Java komponensek, amelyeket példányai által a NOB konténer nevezzük babot, és a NOB konténer kezeli a bab hatályát, életciklus események, és bármely AOP funkciók , amelyre úgy lett beállítva, és kódolt.

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.

A végrehajtó Inversion of Control, egy szoftver / tárgy fogyasztó minél több ellenőrzés / beállítások alatt a szoftver / tárgyak, ahelyett, hogy az ellenőrzött vagy kevesebb lehetőségeket.

Inversion kontroll, mint egy design iránymutatást a következő célokat szolgálja:

Van egy függetlenítése a végrehajtása egy bizonyos feladat végrehajtására.
Minden modul összpontosítani, ami azt tervezték.
Modulok teszik feltételezéseket, milyen más rendszerek, de támaszkodnak a szerződéseket.
Cseréje modulok nincs mellékhatása, hogy más modulok
fogom tartani a dolgokat absztrakt itt, akkor látogasson el a következő linkeket a részletekre megértése a témában.
Egy jó olvasni a példa

Részletes magyarázat

Válaszolt 10/11/2014 08:43
a forrás felhasználó

szavazat
15

Például feladat # 1 objektum létrehozása. Anélkül NOB koncepció, feladat # 1 elvileg történhet Programmer.But A NOB koncepció, feladat # 1 végeznék tartályba.

Röviden Ellenőrző kap invertálhatő programozó tartályba. Tehát, ez az úgynevezett mint a kontroll megfordítása.

Találtam egy jó példa van .

Válaszolt 27/01/2010 13:15
a forrás felhasználó

szavazat
14

Megválaszolása csak az első része. Mi az?

A kontroll megfordítása (NOB) azt jelenti, hogy hozzon létre példányait függőségek első és utóbbi esetben egy osztály (adott esetben az intravénás őket kivitelező), ahelyett, hogy egy például az osztály az első, majd a osztály például példányok létrehozása függőségek. Így, a kontroll megfordítása invertálja a vezérlés menetét a program. Ahelyett, hogy a hívott fél szabályozására az áramlás vezérlő (létrehozása közben függőségek), a hívó áramlását szabályozza a program vezérlését .

Válaszolt 11/01/2016 00:49
a forrás felhasználó

szavazat
14

Úgy tűnik, hogy a leginkább zavaró dolog „NOB” rövidítése, és a nevét, amelyre fennáll, hogy ez túl elbűvölő egy név - szinte zaj nevét.

Valóban szükség van egy nevet, amellyel leírni a különbséget eljárási és eseményvezérelt programozás? OK, ha kell, de nem is kell, hogy válasszon egy új „nagyobb, mint az élet” nevet, amely megtéveszti a több, mint amennyit megold?

Válaszolt 19/01/2011 04:50
a forrás felhasználó

szavazat
13

Hagyja, hogy azt mondják, hogy teszünk egy kis találkozó néhány szállodában.

Sokan, sok kancsó víz, sok műanyag poharak.

Ha valaki akar inni, ő töltse csésze, ital és dobja csésze a padlón.

Óra után, vagy valami van a padló borítja műanyag poharak és a víz.

Let invert ellenőrzés.

Ugyanezen az ülésen ugyanazon a helyen, de ahelyett, műanyag poharak van egy pincér egy üveg csésze (Singleton)

és ő minden alkalommal várja a vendégeket ivott.

Ha valaki akar inni, ő kap pincér üveg, ital és vissza vissza pincér.

Félretéve a kérdést, higiénikus, utolsó formáját ivás folyamatirányító sokkal hatékonyabb és gazdaságosabb.

És pontosan ez az, amit a tavaszi (egy másik NOB konténer, például: Guice) nem. Ahelyett, hogy hagyja, hogy alkalmazás létrehozása, amit szükség felhasználásával új kulcsszót (figyelembe műanyag pohár), Tavaszi NOB konténer minden alkalommal ajánlatot kérelem azonos példány (szingli) a szükséges tárgy (pohár vízzel).

Gondolj magad szervezője ilyen találkozón. Szükség van a módja annak, hogy üzenetet szállodai adminisztráció, hogy

tárgyaló tagjai szükség pohár vizet, de nem rétest.

Példa:-

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

}

Hasznos Linkek:-

Válaszolt 26/09/2012 18:54
a forrás felhasználó

szavazat
13

Egyetértek NilObject , de szeretném felvenni ezt:

ha talál magának másol egy egész eljárást és csak a kis darab a kódot, akkor úgy leküzdése azt a kontroll megfordítása

Ha úgy találja magát a másolás és beillesztés kód körül, akkor szinte mindig csinál valamit rosszul. Kodifikált, mint a tervezési elv csak egyszer .

Válaszolt 06/08/2008 06:20
a forrás felhasználó

szavazat
10

NOB mintegy megfordításával a kapcsolatát a kódot, és a harmadik féltől származó kód (könyvtár / keret):

  • Normális s / w fejlődését, akkor írj a main () módszer és a hívás „library” módszerekkel. Ön az irányítást :)
  • A NOB a „keret” szabályozza a main () , és felhívja a módszereket. A keret irányít :(

DI (Függőség Injection) arról szól, hogy az ellenőrző folyik az alkalmazás. Hagyományos asztali alkalmazást kellett vezérlésfolyam az alkalmazásból (main () metódus) más könyvtári metódushívások, de DI vezérlésfolyam megfordítjuk, ami keret gondoskodik a kiindulási az alkalmazást, inicializáló és hivatkozva a módszereket, amikor szükséges.

A végén mindig nyerni :)

Válaszolt 19/09/2014 19:25
a forrás felhasználó

szavazat
7

Inversion of Control generikus elv, míg függőség Injection felismeri ezt az elvet a mintázata az objektum gráfot építési (azaz konfiguráció szabályozza, hogy milyen tárgyak vannak-e egymással, hanem a tárgy maga szabályozására, hogyan lehet a hivatkozás egy másik objektum).

Nézzük Inversion of Control, mint egy tervezési minta, meg kell nézni, mit is megfordításával. Függőség Injection megfordítja az irányítást létrehozunk egy grafikon tárgyak. Ha azt mondta a laikus idő, a kontroll megfordítása sem módosítja vezérlésfolyam a programban. Például. A hagyományos önálló alkalmazás, van a fő módszer, ahol a szabályozás kerül át más harmadik fél könyvtárak (abban az esetben, már használt harmadik fél könyvtár funkció), hanem a kontroll megfordítása ellenőrzés átkerül a harmadik felek könyvtár kódot kódunkat , ahogy szedi a szolgáltatást harmadik fél könyvtár. De vannak más szempontok, amelyeket meg kell fordított a programon belül - pl hívása módszerek és a szálak, hogy végre a kódot.

Azok számára akik több mélységet Inversion of Control papír már megjelent felvázolja egy teljesebb képet Inversion of Control, mint a mintázata (OfficeFloor: a hivatal mintát javítása szoftver tervezés http://doi.acm.org/10.1145/ 2739011.2739013 egy ingyenes példányt elérhető letölthető http://www.officefloor.net/mission.html )

Mi azonosítjuk az alábbi összefüggést:

A kontroll megfordítása (módszerek) = függőség (állami) Injekciós + folytatás Injekciós + Szál Injekciós

Válaszolt 29/10/2015 04:27
a forrás felhasználó

szavazat
7

Programozási beszélő

NOB könnyű feltételekkel: Ez a használata Interface, mert így az adott valamit (például egy mező vagy paraméter) helyettesítő, hogy lehet használni egyes osztályok. Ez lehetővé teszi az ismételt használhatóságát a kódot.

Például tegyük fel, hogy van két osztály: Kutya és macska . Mind ugyanazok adottságok / kimondja: életkor, méret, tömeg. Tehát ahelyett, hogy a szolgáltatási osztály nevezett DogService és CatService tudok létrehozni egy egy úgynevezett AnimalService , amely lehetővé teszi, hogy használja Kutya és macska csak akkor használja a felületet IAnimal .

Azonban pragmatikusan szólva, hogy van néhány visszafelé.

a) A legtöbb fejlesztő nem tudja, hogyan kell használni . Például, létrehozhat egy osztály nevezett Ügyfél és tudok létrehozni automatikusan (eszközeivel az IDE) interfész nevű ICustomer . Tehát, ez nem ritka az olyan mappát tele osztályok és interfészek, nem számít, ha a felületek lesz újra, vagy sem. Úgy hívják dagadt. Egyesek azt állítják, hogy lehetne „lehet a jövőben tudtuk használni.” : - |

b) Van néhány limitings. Például beszéljünk esetében kutya és macska , és szeretnék, hogy egy új szolgáltatás (funkcionalitás) csak kutyák számára. Tegyük fel, hogy szeretnék számítani a napok számát, amit kell, hogy a vonat egy kutya ( trainDays()), macska ez felesleges, macskák nem lehet tanítani (viccelek).

b1) Ha hozzá trainDays()a szolgáltató AnimalService akkor is működik, macskák, és ez nem érvényes egyáltalán.

b2) tudok adni egy állapot trainDays(), amikor azt vizsgálja, hogy melyik osztályba használunk. De ez megtöri teljesen a NOB.

b.3) tudok létrehozni egy új szolgáltatási osztály nevezett DogService csak az új funkciókat. De, ez növeli a karbantarthatóságának a kód, mert mi lesz két szolgáltatási osztályok (hasonló funkcionalitással) a kutya , és ez rossz.

Válaszolt 19/04/2015 12:07
a forrás felhasználó

szavazat
7

Egy nagyon egyszerű, írásos magyarázatot is itt található

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

azt mondja

„Bármilyen triviális alkalmazás, amely két vagy több osztály, hogy együttműködnek egymással, hogy végre valami üzleti logikát. Hagyományosan minden objektum felelős megszerzésére saját hivatkozásokat objektumokat együttműködik (a függőségek.) Amikor alkalmazása DI, a tárgyak adják függőségek létrehozás időpontjában valamilyen külső entitás, amely koordinálja az egyes objektumok a rendszerben. más szóval, a függőségek fecskendeznek tárgyakat.”

Válaszolt 22/02/2013 15:13
a forrás felhasználó

szavazat
6

Szeretem ezt a magyarázatot: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Úgy indul az egyszerű és megmutatja kód példák is.

írja kép leírása itt

A fogyasztó, X, szüksége van az elfogyasztott osztály, Y, elérni valamit. Ez minden jó és természetes, de nem X igazán tudnia kell, hogy az általa használt Y?

Nem elég, hogy az X tudja, hogy használ valamit, amely a magatartás, a módszerek, tulajdonságok stb., Y ismerete nélkül, akik ténylegesen végrehajtja a viselkedést?

Kinyeri egy elvont definíciója viselkedése által használt X Y szemléltetjük az alábbi I. és hagyta, hogy a fogyasztó X használjon egy példánya, amely ahelyett, hogy Y azt továbbra is megteheti, hogy mit csinál, ha nem ismeri a részleteket arról Y.

írja kép leírása itt

A fenti ábrán látható Y végrehajtja az I. és X. használ egy példánya I. Bár elképzelhető, hogy X Y is használja, ami igazán érdekes az, hogy X nem tudom, hogy. Csak az tudja, hogy használ valamit, hogy végrehajtja az I.

Cikk olvasása további információ és leírás ellátások, mint például:

  • X jelentése nem függ Y többé
  • Rugalmasabb, megvalósítása lehet eldönteni futásidejű
  • Izolálása kód egység, könnyebb tesztelése

...

Válaszolt 16/02/2017 02:03
a forrás felhasználó

szavazat
4

Inversion ellenőrzés körülbelül a vezérlést könyvtár az ügyfélnek. Több értelme, ha beszélünk egy ügyfél, hogy fecskendez (átmegy) függvény értéke (lambda kifejezés) egy magasabb rendű függvény (könyvtári funkció), amely ellenőrzi (változások) viselkedését a könyvtár működését. Az ügyfél vagy keret fecskendez könyvtár függőségeket (hordozó viselkedés) a könyvtárak is figyelembe kell venni NOB

Válaszolt 24/12/2017 18:34
a forrás felhasználó

szavazat
4

Találtam egy nagyon jó példa van , ami megmagyarázza, hogy a „kontroll fordított”.

Klasszikus kód nélkül (Függőség injekció)

Itt van, hogy a kód nem használja DI fog működni nagyjából:

  • Alkalmazás szüksége Ize (pl egy vezérlőt), így:
  • Alkalmazás teremt Foo
  • Alkalmazás felhívja Foo
    • Foo szüksége Bar (pl szolgáltatás), így:
    • Foo teremt Bar
    • Foo felhívja Bar
      • Bár szüksége Bim (a szolgáltatás, egy tár ...), tehát:
      • Bár teremt Bim
      • Bár nem valami

Használata függőséget injekció

Itt van, hogy egy kód segítségével DI fog működni nagyjából:

  • Alkalmazás szüksége Foo, amelynek szüksége van bár, amelynek szüksége van Bim, így:
  • Alkalmazás teremt Bim
  • Alkalmazás teremt Bar és ad neki Bim
  • Alkalmazás teremt Foo és ad neki Bar
  • Alkalmazás felhívja Foo
    • Foo felhívja Bar
      • Bár nem valami

Az irányítást a függőségek fordított egyik hívott az egyik hívás.

Milyen problémákat old meg?

Függőség injekció segítségével könnyen cserélhető a különböző végrehajtását az injektált osztályok. Míg egység tesztelése lehet beadni egy dummy végrehajtását, ami a tesztelés sokkal könnyebb.

Ex: Tegyük az alkalmazás tárolja a felhasználó által feltöltött fájlt a Google Drive, a DI a vezérlő kód így néz ki:

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

Amikor a körülmények változása azt mondják, ahelyett, Google Drive meg kell adnunk, hogy használja a Dropbox. Csak akkor kell írni egy dropbox megvalósítást StorageServiceInterface. Nem kell, hogy bármilyen változás a vezérlő amíg Dropbox végrehajtása tapad a StorageServiceInterface.

Tesztelés közben is létrehozhat az ál a StorageServiceInterface a dummy végrehajtására, ahol az összes módszer return null (vagy bármilyen, előre meghatározott értéket, mint egy a vizsgálati követelmény).

Ehelyett, ha már a vezérlő osztályban megépíteni a tároló objektumot a newkulcsszó, mint ez:

class SomeController
{
    private $storage;

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

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

Ha meg akarjuk változtatni a Dropbox végrehajtásához meg kell cserélni a vonalakat, ahol newGoogleDriveService tárgy van kialakítva, és használja a DropboxService. Emellett, ha a tesztelés SomeController osztály a kivitelező mindig elvárja, hogy a GoogleDriveService osztály és a tulajdonképpeni módszereket ezen osztály indul.

Mikor helyénvaló és mikor nem? Véleményem használja DI ha úgy gondolja, vannak (vagy lehetnek) alternatív megvalósítások egy osztály.

Válaszolt 04/11/2017 13:27
a forrás felhasználó

szavazat
4

Úgy tudom, hogy a válasz már itt megadott. De még mindig úgy gondolom, néhány alapjai inverziós kontroll kell itt tárgyalt hosszúak a jövőben az olvasók.

Inversion of Control (NOB) már épül egy nagyon egyszerű elv az úgynevezett Hollywood elve . És azt mondja, hogy,

Ne hívjon minket, majd hívlak

Ez azt jelenti, hogy nem megy a hollywoodi teljesíteni álmai inkább, ha méltó majd Hollywood fog találni, és az álmod valóra válik. Elég sokat fordított, mi?

Most, amikor megvitatjuk elvének NOB használjuk megfeledkezni a Hollywood. Mert NOB, ott kell lennie a három elem, Hollywood, te és a feladat szeretnék teljesíteni álmai.

A mi progamozóknak, Hollywood képviselnek általános keretet (lehet Ön által írt vagy valaki más), akkor képviseli a felhasználói kódot írt, és a feladat képviseli a dolog, amit szeretnénk elérni a kódot. Most már soha ne menj kiváltani a feladat egyedül, nem NOB! Inkább már terveztek mindent úgy, hogy a keret előidézik a feladatot. Így építettünk egy újrafelhasználható keretet, amely lehet, hogy valaki egy hős vagy egy másik gazember. De ez a keret nem mindig felel meg tudja, mikor kell felvenni valakit, és hogy valaki tudja, hogy mi akar lenni.

Egy valós példa lenne megadni. Tegyük fel, azt szeretnénk, hogy dolgozzon ki egy webes alkalmazás. Tehát, ha egy olyan keret, amely kezeli az összes közös dolog egy webes alkalmazás kezelje, mint a kezelési http kérés, ami alkalmazás menüben, szolgáló oldalak, a cookie-k, stb kiváltó események

És akkor némi horgok a keretet, ahol fel további kódokat generálni egyéni menü oldalak, sütemény vagy bejelentkezve egyes felhasználói események stb minden böngészőben kérésre a keretet fog futni, és végrehajtja az egyéni kódot, ha akasztott majd tálaljuk vissza a böngészőnek.

Tehát az ötlet nagyon sok egyszerű. Ahelyett, hogy a felhasználói alkalmazás, amely mindent irányít, először hozzon létre egy újrafelhasználható keretet fogja ellenőrizni mindent majd írjuk meg az egyéni kódok és akassza a keret, hogy végre ezeket az időben.

Laravel és EJB példák az ilyen keretek.

Referencia:

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

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

Válaszolt 01/10/2017 11:24
a forrás felhasználó

szavazat
4

NOB is ismert függőség injekció (DI). Ez egy folyamat, amelynek során tárgyakat meghatározzák a függőségek, azaz a többi tárgy is működnek, csak a konstruktorargumentum, érvek a gyári módszer, illetve tulajdonságok beállítása Az objektum példány után épített vagy vissza a gyári módszer . A tartályt ezután fecskendez a függőségek, amikor elkészíti a bab. Ez a folyamat alapvetően az inverz, innen a név a kontroll megfordítása (NOB), a bab önmagában vezérlésére példányosítását vagy helyét annak függőségek segítségével közvetlen építési osztályok, vagy egy olyan mechanizmus, mint például a Service Locator minta

Tavaszi-keret-referance.pfd 27. oldal (ha számít minden pdf dokumentum oldalakat, akkor a 51. oldalon)

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

Válaszolt 24/01/2013 15:52
a forrás felhasználó

szavazat
3

Inversion ellenőrzés van, amikor elmész a boltba, és a felesége adja a termékek listáját vásárolni.

A programozás szempontjából, amikor elment egy visszahívási funkció getProductList()a funkciót hajtanak végre doShopping();

Ez lehetővé teszi, hogy a felhasználó a funkció határozza meg egyes részei így rugalmasabb.

Válaszolt 15/12/2017 18:35
a forrás felhasználó

szavazat
3

Fogalmának megértéséhez, Inversion of Control (NOB), vagy függőség Inversion Principle (DIP) magában foglalja a két tevékenység: kivételi, és inverzió. Függőségi Injection (DI) csak egyike azon kevés az inverziós módszerekkel.

Ha szeretne többet megtudni ezt el tudja olvasni a blogomat Itt

  1. Mi az?

Ez egy gyakorlat, ahol hagyja, hogy a tényleges viselkedés kívülről érkezik a határ (Class objektumorientált programozás). A határ egység csak annyit tud a kivételi (pl felület, absztrakt osztály, küldöttje objektumorientált programozás) is.

  1. Milyen problémákat old meg?

Távon a programozás NOB próbálja megoldani monolit kódot azáltal, hogy moduláris, függetlenítés különböző részeit, és azt unit-tesztelhető.

  1. Mikor helyénvaló és mikor nem?

Helyénvaló a legtöbb időt, ha van helyzet, amikor csak szeretné monolit kód (pl nagyon egyszerű program)

Válaszolt 03/06/2016 01:46
a forrás felhasználó

szavazat
3

Létrehozása egy objektum osztály: az úgynevezett szoros összekapcsolódás, Spring eltávolítja ezt a függőséget az alábbiak szerint: a mintázata (DI / IOC). Mely tárgya osztály telt kivitelező létrehozása helyett az osztályban. További felett adunk szuper osztály referencia változó kivitelező, hogy határozza meg az általános szerkezetét.

Válaszolt 13/05/2015 08:52
a forrás felhasználó

szavazat
3
  1. Tehát az 1. számú fent . Mi Inversion of Control?

  2. Karbantartás az első számú dolog, ez megoldja a számomra. Ez garantálja Én használ interfészeket, hogy a két osztály nem intim egymással.

Az egy konténer, mint Castle Windsor, ez megoldja a karbantartási problémákat, még jobb. Hogy képes cserélhető ki egy alkatrész, hogy megy egy adatbázis, amelyik használ fájl alapú perzisztencia megváltoztatása nélkül egy sor kód félelmetes (konfigurációs módosítást, akkor kész).

És ha egyszer kap a generikumok, még jobb lett. Képzelj el egy olyan üzenetet megjelenítő, amely befogadja nyilvántartások és közzéteszi üzeneteket. Nem érdekel, mit tesz közzé, de szüksége van egy leképező, hogy valamit egy rekordot egy üzenetet.

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

Írtam egyszer, de most is beadhatják sokféle ebbe kódegyüttesnek ha azt közzé különböző típusú üzeneteket. Azt is írja, hogy mappers hogy egy rekord az azonos típusú és térkép őket különböző üzeneteket. Használata DI generikus adott nekem képes írni nagyon kevés kódot véghezvinni sok feladatot.

Ja, vannak tesztelhetőségi aggályok, de ezek másodlagos előnyeit NOB / DI.

Én feltétlenül szerető NOB / DI.

3. Ez válik a megfelelő pillanatban az, hogy van egy közepes méretű projekt valamivel több komplexitás. Azt mondanám, ez lesz a megfelelő a pillanatban indul érzés fájdalom.

Válaszolt 19/09/2008 05:59
a forrás felhasználó

szavazat
2

Segítségével NOB Ön nem new'ing fel a tárgyakat. A NOB konténer fog tenni, hogy kezelni és az élettartam őket.

Ez megoldja a problémát, hogy manuálisan változtatni minden példányosítását egyféle tárgy a másikra.

Célszerű, ha van alkalmassága, hogy megváltozhat a jövőben, vagy, hogy eltérő lehet attól függően, hogy a környezet vagy a konfiguráció használt.

Válaszolt 16/07/2015 16:06
a forrás felhasználó

szavazat
1

Olvastam egy csomó választ erre, de ha valaki még mindig zavaros, és szüksége van egy plusz ultra „laymans kifejezés” megmagyarázni NOB itt az én veszi:

Képzeljünk el egy szülő és a gyermek beszél egymással.

Anélkül NOB:

* Szülő : Csak beszélni, ha kérem kérdésekre, és csak akkor lehet fellépni, ha engedélyt nem adok rá.

Szülő : Ez azt jelenti, akkor ne kérdezze, ha lehet enni, játszani, menj a fürdőszobába, vagy még aludni, ha nem kérem.

Szülő : Akarsz enni?

Gyermek : Nem

Szülő : Rendben, itt leszek. Várj meg.

Gyermek : (játszani akar, de mivel ez nem kérdés a szülő, a gyermek nem tud semmit).

1 óra után...

Szülő : itt vagyok. Akarsz játszani?

Gyermek : Igen.

Szülő : Az engedélyt megadom.

Gyermek : (végre képes lejátszani).

Ez az egyszerű forgatókönyv ismerteti az ellenőrzés középpontjában a szülőnek. A gyermek szabadság korlátozott és nagymértékben függ a szülő kérdésére. A gyermek csak beszélni, amikor felkérték, hogy beszéljen, és csak cselekedni, ha engedélyt.

NOB:

A gyermeknek már képes kérdéseket feltenni, és a szülő tud válaszolni a választ, és engedélyeket. Egyszerűen azt jelenti, hogy a vezérlő fordított! A gyermek most már szabadon kérdezzen bármikor és bár még mindig függés a szülő kapcsolatos jogosultságokat, ő nem függ az eszközök beszélő / kérdéseket.

A technológiai módon megmagyarázni, ez nagyon hasonlít a konzol / shell / cmd vs GUI interakció. (Ami válasz Mark Harrison fent No.2 felső válasz). A konzol, akkor függ a mire kérünk / jelenik meg, és Ön nem tud ugrani más menük és funkciók válasz nélkül ez kérdés első; következő szigorú szekvenciális áramlását. (programból ez olyan, mint egy eljárás / funkció hurok). Azonban a GUI, a menük és funkciók vannak lefektetve, és a felhasználó választhat bármilyen szükséges tehát, hogy több ellenőrzés és kevésbé korlátozott. (programozottan menük visszahívás, ha a kiválasztott és cselekvés végbemegy).

Válaszolt 07/08/2019 02:45
a forrás felhasználó

szavazat
1

A legelső változata Java EE (J2EE idején) bevezette a inverzió a kontroll (NOB), ami azt jelenti, hogy a tartály venné az irányítást az üzleti kódot, és technikai szolgáltatásokat (mint például a tranzakciós és biztonsági menedzsment).

Válaszolt 03/04/2017 22:42
a forrás felhasználó

szavazat
0

Mivel már sok választ a kérdésre, de egyikük sem eloszlását mutatja inverziós ellenőrző távon látok lehetőséget ad a tömörebb és hasznos választ.

Megfordítása Control egy minta, amely végrehajtja a Dependency inverziós elvnek (DIP). DIP állapotok a következők: 1. Magas szintű modulok nem függhet az alacsony szintű modulokat. Mindkettő függ absztrakciók (pl interfészek). 2. absztrakciók nem függ a részleteket. Részletek (beton implementáció) kell függenie absztrakciók.

Három fajta Inversion of Control:

Interface Inversion szolgáltatók nem határozhatja meg egy interfész. Ehelyett a fogyasztó határozza meg a felületet, és gondoskodniuk kell végrehajtani. Interface Inversion lehetővé nem teszi szükségessé, hogy módosítsa a fogyasztó minden egyes alkalommal, amikor egy új szolgáltató hozzá.

Az áramlás megfordítása Változások áramlásának szabályozását. Például, ha van egy konzolos alkalmazás, ahol meg kell adnunk sok paraméter, és mindegyik után lépett a paraméter akkor kénytelenek nyomja meg az Entert. Akkor lehet alkalmazni, Flow Inversion ide és végre egy asztali alkalmazás, ahol a felhasználó választhat a sorozat paraméterek belépő, a felhasználó szerkesztheti, és az utolsó lépés, a felhasználói igények nyomja meg az Entert csak egyszer.

Creation Inversion Ez úgy valósítható meg, az alábbi minták: Factory Pattern, Service Locator függőség Injection. Creation Inversion segít eltávolítani a függőségek típusai között mozog a folyamat függőségi objektumok létrehozását kívül a típus, amely ezeket függőségi objektumokat. Miért függőségek rossz? Íme néhány példa: közvetlen létrehozása egy új objektumot a kódban egyszerű tesztelés nehezebb; lehetetlen megváltoztatni referenciákat szerelvények újrafordítás nélkül (OCP elv megsértése); nem lehet olyan könnyen helyettesíti a desktop-UI egy web-UI.

Válaszolt 12/08/2019 18:36
a forrás felhasználó

szavazat
0

Tényleg nem értik, hogy miért van sok rossz választ, és még az elfogadott nem egészen pontos, hogy a dolgok nehéz megérteni. Az igazság mindig egyszerű és tiszta.

Ahogy @Schneider kommentálta a @Mark Harrison válasza , kérjük csak olvasni Martin Fowler utáni megvitatása NOB.

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

Az egyik, akit szeretek:

Ez a jelenség Inversion of Control (más néven a hollywoodi elv - „Ne hívjon minket, majd hívlak”).

Miért?

Wiki NOB , talán idézni egy részletet.

Inversion kontroll növelésére használt moduláris program, és ez bővíthető ... majd tovább népszerűsítette 2004-ben Robert C. Martin és Martin Fowler .

Robert C. Martin: a szerző <<Clean Code: A Handbook of Agile Software Craftsmanship>>.

Martin Fowler: a szerző <<Refactoring: Improving the Design of Existing Code>>.

Válaszolt 09/05/2019 03:39
a forrás felhasználó

szavazat
0

Ahhoz, hogy megértsük NOB, meg kell beszélni Függőség Inversion.

Függőség inverzió: Függ absztrakciók nem concretions.

Inversion ellenőrzés: Fő vs absztrakció, és hogyan a Fő a ragasztó a rendszerek.

DIP és a NOB

Ezek közül néhány jó állásokat beszél erről:

https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/

https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/

https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/

Válaszolt 13/04/2019 14:58
a forrás felhasználó

szavazat
0

Mi az? Megfordítása (összekapcsolás) vezérlő, megváltoztatja az irányát összekötők a módszerrel aláírást. Fordított szabályozás, a meghatározása a módszer aláírás által diktált módszer végrehajtását (és nem a hívó a módszer). Teljes magyarázat itt

Ami problémát old meg? Felülről lefelé kapcsolási módszerekről. Ezt követően lecsökken a újratervezés.

Mikor helyénvaló és mikor kell használni és mikor nem? A kis jól meghatározott alkalmazások, amelyek nem tartoznak a sok változás, akkor valószínűleg nem a feje fölött. Azonban, a kevésbé meghatározott alkalmazásokat, amelyek fejlődnek, ez csökkenti a benne rejlő kapcsolási módszer aláírás. Ez ad a fejlesztők nagyobb szabadságot fejlődni az alkalmazás, így nem kell tennie, drága újratervezés kódot. Alapvetően lehetővé teszi az alkalmazás fejlődik kis utómunka.

Válaszolt 28/02/2019 17:37
a forrás felhasználó

szavazat
0

Inversion ellenőrzés azt jelenti, hogy ellenőrizzék, milyen alkatrészek (osztályok) viselkednek. Miért az úgynevezett „inverzió”, mert mielőtt ezt a mintát az osztályok voltak a huzalozott és volt végleges, hogy mit fognak csinálni pl

importált egy könyvtár, amely egy TextEditorés SpellCheckerosztályok. Most természetesen ez SpellCheckercsak ellenőrizni helyesírású angol nyelven. Tegyük fel, ha azt szeretné, TextEditorhogy kezelni német nyelv és képes legyen helyesírás-ellenőrzés bármilyen irányítást felette.

A NOB ezen ellenőrző megfordítjuk, azaz annak adott neked, hogyan? A könyvtár végrehajtja, valahogy így:

Ez lesz a TextEditorosztály és akkor lesz egy ISpeallChecker(ami egy interfész helyett beton SpellCheckerosztály), és ha konfigurálni a dolgokat NOB konténer pl Spring tud nyújtani a saját végrehajtását „ISpellChecker”, amely ellenőrzi helyesírás német nyelvet. így a szabályozás, hogy milyen a helyesírás-ellenőrzés fog működni a ineverted veszünk, hogy a könyvtár és adott neked. Amit NOB.

Válaszolt 14/02/2019 23:03
a forrás felhasználó

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