Ce este Inversarea de control?

voturi
1k

Inversarea de control (sau IOC) poate fi destul de confuz atunci când aceasta este prima întâlnit.

  1. Ce este?
  2. Ce probleme rezolva?
  3. Când este cazul și dacă nu?
Întrebat 06/08/2008 la 04:35
sursa de către utilizator
În alte limbi...                            


32 răspunsuri

voturi
1k

Inversiunea de control (IOC) și modelele Dependență de injecție (DI) sunt toate despre eliminarea dependențele din codul.

De exemplu, să presupunem aplicația are o componentă de editor de text și doriți să furnizați și verificarea ortografică. Codul dvs. standard, ar arata ceva de genul:

public class TextEditor {

    private SpellChecker checker;

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

Ceea ce am făcut aici , creează o dependență între TextEditorși SpellChecker. Într - un scenariu IoC ne - ar face în schimb ceva de genul:

public class TextEditor {

    private IocSpellChecker checker;

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

În primul exemplu de cod suntem instantiind SpellChecker( this.checker = new SpellChecker();), ceea ce înseamnă TextEditorclasa depinde direct de SpellCheckerclasa.

În al doilea exemplu de cod vom crea o abstracție de având SpellCheckerclasa de dependență în TextEditorsemnătură constructor (nu inițializarea dependență în clasă). Acest lucru ne permite să numim dependența apoi trece - l la clasa Texteditor astfel:

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

Acum , clientul crearea TextEditorclasei are controlul asupra căreia SpellCheckerpunerea în aplicare a utiliza , deoarece suntem injectarea dependența de TextEditorsemnătură.

Acesta este doar un exemplu simplu, există o serie bună de articole de Simone Busoli care explică mai în detaliu.

Publicat 06/08/2008 la 08:22
sursa de către utilizator

voturi
485

Inversiune de control este ceea ce obții atunci când callback dvs. din program, de exemplu, ca un program de gui.

De exemplu, într-un meniu de școală veche, s-ar putea avea:

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

controlând astfel fluxul de interacțiune cu utilizatorul.

Într-un program de GUI sau somesuch, în loc să spunem

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

Deci, acum este controlul, inversat ... în loc de a accepta calculator datele introduse de utilizator într-o ordine fixă, utilizatorul controlează ordinea în care este introdus datele, iar în cazul în care datele sunt salvate în baza de date.

Practic, orice cu o buclă de eveniment, callback-uri, sau de a executa declanșatoare se încadrează în această categorie.

Publicat 06/08/2008 la 06:42
sursa de către utilizator

voturi
356

Ce este Inversarea de control?

Dacă urmați acești pași simpli doi, ați făcut inversarea controlului:

  1. Separată ce -sa- a face parte din când -sa- a face parte.
  2. Asigurați - vă că , atunci când o parte știe cât puțin posibil despre ce parte; si invers.

Există mai multe tehnici posibile pentru fiecare dintre aceste etape bazate pe tehnologia / limba pe care o utilizați pentru implementarea.

-

Inversiune parte a inversiunii de control (IOC) este un lucru confuz; deoarece inversiune este termenul relativ. Cel mai bun mod de a înțelege IoC este de a uita despre acest cuvânt!

-

Exemple

  • Eveniment de manipulare. Manipulatorii EVENT (ceea ce-to-face parte) - Evenimente Creșterea (când-to-do parte)
  • Interfețe. Componenta de client (atunci când-to-face parte) - punerea în aplicare interfață Component (ceea ce-to-face parte)
  • xUnit fixure. Configurare și deconectare (ceea ce-to-do r) - cadre xUnit apeluri la instalare la începutul și la sfârșitul teardown (când-to-face parte)
  • Format model de design metoda. Metoda șablon atunci când-to-face parte - implementarea subclase primitivă ce-a-face parte
  • DLL metode de containere în COM. DllMain, DllCanUnload, etc (ce-to-do parte) - COM / OS (când-to-do parte)
Publicat 22/07/2010 la 18:34
sursa de către utilizator

voturi
81

Inversarea comenzilor este de aproximativ separare preocupări.

Fără IoC : Aveți un laptop calculator și vă rupe accidental pe ecran. Și darn, veți găsi același ecran model de laptop este nicăieri în piață. Deci , ești blocat.

Cu IoC : Ai un desktop - ul computerului și vă rupe accidental pe ecran. Tu poți găsi apuca doar aproape orice monitor de birou de pe piață, și funcționează bine cu desktop - ul tau.

Desktop-ul pune în aplicare cu succes IoC în acest caz. Acesta acceptă un tip varietate de monitoare, în timp ce laptop-ul nu, are nevoie de un anumit ecran pentru a obține fix.

Publicat 25/09/2013 la 15:24
sursa de către utilizator

voturi
77

Inversarea de control, (sau IOC), este vorba despre obtinerea de libertate (te casatoresti, ai pierdut libertatea si sunt controlate. Ai divorțat, ai pus în aplicare doar inversiune de control. Asta e ceea ce am numit „decuplat“. Bun sistem de calculator descurajează o relație foarte strânsă.) flexibilitate mai mare (bucătăria din birou servește doar apă curată de la robinet, care este singura opțiune atunci când doriți să bea. seful tau a implementat Inversarea de control prin crearea unei noi mașini de cafea. acum , veți obține flexibilitatea de a alege fie apa de la robinet sau cafea.) și mai puțin de dependență (partenerul tau are un loc de muncă, nu au un loc de muncă, va depinde financiar de partenerul tau, deci sunt controlate. Veti gasi un loc de muncă, ați implementat Inversarea de control. bun sistem de calculator încurajează în dependență.)

Când utilizați un computer desktop, ați slaved (sau spune, controlate). Trebuie să stai în fața unui ecran și uita-te la ea. Folosind tastatura pentru a introduce și folosind mouse-ul pentru a naviga. Și un software prost scris de sclavi poți chiar mai mult. Dacă înlocuiți desktop-ul cu un laptop, atunci ai inversat oarecum de control. Puteți să-l lua cu ușurință și de a se deplasa. Deci, acum puteți controla în cazul în care vă aflați cu computerul, în loc să-l computerul de control.

Prin implementarea Inversarea de control, un consumator software / obiect obține mai multe controale / opțiuni asupra software / obiectelor, în loc să fie controlate sau care au mai puține opțiuni.

Cu ideile de mai sus în minte. Noi încă dor de o parte esențială a IoC. În scenariul de IOC, consumatorul de software / obiect este un cadru sofisticat. Asta înseamnă codul pe care a creat nu este numit de unul singur. Acum, să explice de ce acest mod funcționează mai bine pentru o aplicație web.

Să presupunem că codul este un grup de muncitori. Ei au nevoie pentru a construi o mașină. Acești lucrători au nevoie de un loc și instrumente (un cadru software) pentru a construi masina. Un tradițional cadru software va fi ca un garaj cu mai multe instrumente. Deci , muncitorii trebuie să facă un plan de ei înșiși și de a folosi instrumentele necesare pentru a construi masina. Construirea unei mașini nu este o afacere ușoară, va fi foarte greu pentru lucrătorii să -și planifice și să coopereze în mod corespunzător. Un modern , cadru software va fi ca o fabrică de automobile moderne , cu toate facilitățile și manageri în loc. Lucrătorii nu trebuie să facă nici un plan, managerii (parte a cadrului, ei sunt cei mai destepti oameni și a făcut planul cel mai sofisticat) va ajuta la coordonarea , astfel încât lucrătorii să știe când să -și facă treaba (cadru solicită codul). Lucrătorii trebuie doar să fie suficient de flexibile pentru a utiliza orice instrumente managerii le dau acestora (prin utilizarea Dependență Injection).

Deși lucrătorii dau controlul gestionării proiectului la nivelul superior managerilor (Cadrul general). Dar este bine să avem niște profesioniști ajuta. Acesta este conceptul de IoC cu adevărat provin de la.

unor aplicații web moderne, cu o arhitectură MVC depinde de cadrul de a face URL-ul de rutare și de a pune în aplicare controlere pentru cadrul pentru a apela.

Dependență Injectarea și Inversarea de control sunt legate. Dependență Injectarea este la micro - nivel și Inversarea de control este la macro nivel. Trebuie să mănânce în fiecare mușcătură (punerea în aplicare a DI) pentru a termina o masă (punerea în aplicare a IOC).

Publicat 04/03/2013 la 20:33
sursa de către utilizator

voturi
72

Înainte de a utiliza Inversarea de control ar trebui să fie conștienți de faptul că are argumente pro și contra și ar trebui să știi de ce-l utilizați dacă faceți acest lucru.

Pro:

  • Codul dvs. este decuplat, astfel încât să puteți schimba cu ușurință implementări ale unei interfețe cu implementări alternative
  • Este un motivator puternic pentru codificare împotriva interfețe în loc de implementări
  • Este foarte ușor să scrie teste unitare pentru codul dvs., deoarece depinde de nimic altceva decât obiectele pe care le acceptă în sale constructor / setteri și le puteți inițializa cu ușurință cu obiectele potrivite în mod izolat.

Contra:

  • IoC nu numai că inversează fluxul de control în programul tău, îl umbrește, de asemenea, considerabil. Acest lucru înseamnă că nu se mai poate citi doar codul si sari de la un loc la altul, deoarece conexiunile care ar fi în mod normal, în codul dvs. nu sunt în codul de mai. În schimb, este în fișierele de configurare XML sau adnotări și în codul containerului IoC care interpretează aceste metadate.
  • Acolo apare o nouă clasă de bug-uri pe care obțineți de configurare XML sau adnotările dvs. greșit și puteți petrece o mulțime de timp a afla de ce containerul IoC injecteaza o referință nulă într-unul dintre obiectele în anumite condiții.

Personal, am vedea punctele forte ale IoC și îmi place foarte mult de ele, dar am tendința de a evita IoC ori de câte ori este posibil, deoarece se transformă software-ul într-o colecție de clase care nu mai constituie un „real“ de program, ci doar ceva care trebuie să fie puse împreună de configurare XML sau metadate adnotări și ar cădea (și cade), în afară fără ea.

Publicat 12/02/2010 la 15:31
sursa de către utilizator

voturi
55
  1. Articolul Wikipedia . Pentru mine, inversiunea de control se transformă codul secvențial scris și transformându - l într - o structură de delegare. În loc de programul de control în mod explicit totul, programul stabilește o clasă sau o bibliotecă cu anumite funcții care urmează să fie numit atunci când anumite lucruri se întâmplă.

  2. Se rezolvă codul de duplicare. De exemplu, în zilele vechi pe care ar scrie manual propriul bucla eveniment de votare bibliotecile de sistem pentru evenimente noi. In prezent, cele mai multe API-uri moderne vă spun pur și simplu bibliotecile de sistem ce evenimente care vă interesează, și va anunța când se întâmplă.

  3. Inversiune de control este un mod practic de a reduce duplicarea de cod, și dacă vă găsiți copiați o întreagă metodă și schimbarea numai o mică bucată de cod, puteți lua în considerare abordarea cu inversiune de control. Inversarea de control este ușor de făcut în mai multe limbi prin conceptul de delegați, interfețe sau indicii cu funcții chiar și prime.

    Nu este necesar să se folosească, în toate cazurile, deoarece fluxul unui program poate fi mai greu de urmat atunci când în scris în acest fel. Este un mod util de a proiecta metode atunci când scrieți o bibliotecă care va fi reutilizată, dar ar trebui să fie utilizate cu moderație în miezul propriului program excepția cazului în care rezolvă într-adevăr o problemă de cod de duplicare.

Publicat 06/08/2008 la 05:33
sursa de către utilizator

voturi
38

Dar cred că trebuie să fie foarte atent cu ea. Daca va folositi prea mult pentru acest model, va face un design foarte complicat și codul chiar mai complicat.

La fel ca în acest exemplu cu Texteditor: dacă aveți doar un singur ortografic poate că nu este cu adevărat necesar să se utilizeze IoC? Cu excepția cazului în care aveți nevoie pentru a scrie teste unitare sau ceva ...

Oricum ar fi : să fie rezonabil. Model de design sunt bune practici , dar nu Biblia să fie predicat. Nu - l lipesc peste tot.

Publicat 06/08/2008 la 23:08
sursa de către utilizator

voturi
34

Să presupunem că sunteți un obiect. Și te duci la un restaurant:

Fără IoC : vă întreb pentru „măr“, și vă sunt întotdeauna servite de mere , atunci când vă întreb mai mult.

Cu IoC : Puteți cere „fructe“. Puteți obține diferite fructe de fiecare dată când te servit. de exemplu, mere, portocale sau pepene verde.

Deci, în mod evident, IoC este de preferat atunci când doriți soiurile.

Publicat 25/09/2013 la 15:00
sursa de către utilizator

voturi
34

IoC / DI pentru mine este împingând dependențe la obiectele de apelare. Super simplu.

Răspunsul non-techy este posibilitatea de a schimba dintr-un motor într-o mașină chiar înainte de al porni. Dacă totul cârlige dreapta (interfața), ești bun.

Publicat 19/09/2008 la 03:54
sursa de către utilizator

voturi
23
  1. Inversiune de control este un model utilizat pentru decuplarea componentelor și straturilor în sistem. Modelul este implementat prin injectarea dependențelor într-o componentă atunci când este construit. Aceste dependințe sunt furnizate, de obicei ca interfețe pentru decuplare în continuare și pentru a sprijini testabilitatea. containere IoC / DI, cum ar fi Castelul Windsor, Unitatea sunt instrumente (biblioteci), care pot fi utilizate pentru a furniza IoC. Aceste instrumente oferă caracteristici extinse de mai sus și dincolo de gestionarea dependenței simplu, inclusiv durata de viață, AOP / intercepție, politica, etc.

  2. A. Îndepărtează o componentă de a fi responsabilă pentru gestionarea dependențe Este.
    b. Oferă posibilitatea de a schimba implementările de dependență în diferite medii.
    c. Permite unei componente să fie testate prin batjocoritoare de dependențe.
    d. Oferă un mecanism de repartizare a resurselor pe parcursul unei cereri.

  3. A. Critice atunci când faci de dezvoltare condusă de teste. Fără IoC poate fi dificil de a testa, deoarece componentele de testat sunt foarte cuplate la restul sistemului.
    b. Critice atunci când dezvoltarea de sisteme modulare. Un sistem modular este un sistem ale cărui componente pot fi înlocuite fără a necesita recompilarea.
    c. Critice în cazul în care există mai multe probleme transversale care trebuie abordate, partilarly într - o aplicație de întreprindere.

Publicat 19/09/2008 la 03:27
sursa de către utilizator

voturi
17

Voi scrie pe înțelegerea mea simplă a acestui doi termeni:

For quick understanding just read examples*

Dependency Injection (DI):
Dependență injecție înseamnă , în general , care trece un obiect pe care metoda depinde, ca parametru la o metodă, mai degrabă decât metoda a crea obiectul dependent .
Ce înseamnă , în practică , este că metoda nu depinde în mod direct pe o anumită punere în aplicare; orice implementare care îndeplinește cerințele pot fi transmise ca parametru.

Cu acest obiecte spune dependențe Thier. Și de primăvară îl pune la dispoziție.
Acest lucru duce la fragila dezvoltare de aplicații.

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

Inversarea de control (IOC) Container:
Aceasta este o caracteristică comună a cadrelor, IOC gestionează obiecte Java
- de la instanțierea la distrugere prin BeanFactory sale.
-Java componente care sunt instanțiate de către container IoC sunt numite fasole, iar containerul IoC gestionează domeniul de aplicare de fasole lui, evenimentele ciclului de viață, precum și orice caracteristici AOP pentru care a fost configurat și codificate.

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.

Prin implementarea Inversarea de control, un consumator software / obiect obține mai multe controale / opțiuni asupra software / obiectelor, în loc să fie controlate sau care au mai puține opțiuni.

Inversarea de control, ca un ghid de proiectare are următoarele obiective:

Există o decuplare a executării unei anumite sarcini de punere în aplicare.
Fiecare modul poate concentra asupra a ceea ce este proiectat pentru.
Modulele face presupuneri cu privire la ceea ce fac alte sisteme , dar se bazează pe contractele lor.
Înlocuirea modulelor nu are nici un efect secundar asupra altor module ,
voi păstra lucruri abstracte aici, puteți vizita următoarele link - uri pentru detalii înțelegere a subiectului.
Un bun exemplu de citire cu

Explicatie detaliata

Publicat 10/11/2014 la 08:43
sursa de către utilizator

voturi
15

De exemplu, sarcina # 1 este de a crea obiect. Fără concept de IOC, sarcina # 1 ar trebui să fie făcut de către Programmer.But Cu conceptul IOC, sarcina # 1 ar fi făcut de container.

Pe scurt de control devine inversat de la programator la container. Deci, este numit ca inversiune de control.

Am găsit un exemplu bun aici .

Publicat 27/01/2010 la 13:15
sursa de către utilizator

voturi
14

Răspunsul doar prima parte. Ce este?

Inversion of Control (IoC) înseamnă a crea cazuri de dependențe prima și ultima instanță a unei clase (opțional injectarea lor prin constructor), în loc să creeze o instanță a clasei întâi și apoi instanța de clasă a crea instanțe de dependențe. Astfel, inversarea controlului inversează fluxul de control al programului. In loc de controlul callee fluxului de comandă ( în timp ce crearea dependențe), al apelantului controlează fluxul de control al programului .

Publicat 11/01/2016 la 00:49
sursa de către utilizator

voturi
14

Se pare că cel mai confuz despre „IoC“, acronimul și numele pentru care stă este că e prea plin de farmec al unui nume - aproape un nume de zgomot.

Nu avem nevoie într-adevăr un nume prin care să descrie diferența dintre programarea procedurală și evenimentul condus? OK, dacă avem nevoie, dar avem nevoie pentru a alege un nou brand „mai mare decât viața“, nume care confundă mai mult decât rezolvă?

Publicat 19/01/2011 la 04:50
sursa de către utilizator

voturi
13

Să să spunem că vom face unele întâlnire într-un hotel din.

Mulți oameni, multe carafe de apa, in mai multe pahare de plastic.

Când cineva doresc să bea, ea umple cupa, bea si arunca cupa pe podea.

După o oră sau ceva avem un etaj acoperit de pahare de plastic și apă.

Să controlul invertit.

În aceeași ședință, în același loc, dar în loc de pahare din plastic avem un chelner cu o cana de sticlă (Singleton)

și ea tot timpul ofera oaspetilor de baut.

Când cineva doresc să bea, ea obține din sticlă chelner, bea și să se întoarcă înapoi la chelner.

Lăsând la o parte problema igienică ultima formă de control al procesului de băut, este mult mai eficientă și economică.

Și acest lucru este exact ceea ce primăvara (un alt recipient IOC, de exemplu: Guice) nu. În loc de let pentru a crea aplicații care au nevoie folosind un cuvânt cheie nou (luând cana de plastic), de primăvară IoC container toate oferta de timp pentru cererea de exemplu aceeași (Singleton) de obiect necesar (pahar cu apă).

Gândiți-vă ca organizator a unei astfel de întâlnire. Ai nevoie de mod de administrare mesaj la hotel care

Membrii reuniune va avea nevoie de pahar de apă, dar nu bucată de tort.

Exemplu:-

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

}

Link-uri utile:-

Publicat 26/09/2012 la 18:54
sursa de către utilizator

voturi
13

Sunt de acord cu NilObject , dar aș vrea să adaug la acest lucru:

dacă vă aflați copiați o întreagă metodă și schimbarea numai o mică bucată de cod, puteți lua în considerare abordarea cu inversiune controlului

Dacă vă aflați copiați și inserați codul în jurul valorii de , te aproape întotdeauna faci ceva greșit. Codifice ca principiu de proiectare O dată și o singură dată .

Publicat 06/08/2008 la 06:20
sursa de către utilizator

voturi
10

IoC este despre răsturnând relația dintre codul dvs. și codul terță parte (bibliotecă / cadru):

  • În s normale / w dezvoltare, scrieți principal () metoda și numesc metode de „bibliotecă“. Sunteți în control :)
  • În IoC „cadrul“ controlează principal () și solicită metodele. Cadrul este în control :(

DI (Dependență Injection) este despre modul în care fluxurile de control în cerere. aplicație desktop tradițională a avut de control al fluxului din aplicația (metoda principală ()) la alte apeluri de metode de bibliotecă, dar cu DI fluxului de control este inversat, care este cadru are grijă de a începe aplicația, initializarea si invocand metodele de ori de câte ori este necesar.

În final vei câștiga întotdeauna :)

Publicat 19/09/2014 la 19:25
sursa de către utilizator

voturi
7

Inversiune de control este un principiu generic, în timp ce Dependență Injection realizează acest principiu ca un model de proiectare pentru constructii grafic obiect (de exemplu, controalele de configurare modul în care obiectele sunt referire la ele, mai degrabă decât obiectul în sine care controlează modul în care pentru a obține trimiterea la un alt obiect).

Privind la Inversare de control, ca un model de design, trebuie să ne uităm la ceea ce răsturnând. Dependență Injectarea inversează controlul de a construi un grafic de obiecte. În cazul în care a spus în termen de nespecialist, inversarea controlului implică modificarea fluxului de control al programului. De exemplu. În aplicație independentă tradițională, avem metoda principală, de unde controlul devine trecut la alte biblioteci terțe părți (în cazul în care, am folosit funcția de a treia biblioteca părți), ci prin inversarea controlului de control este transferat de la terțe părți cod bibliotecă pentru codul nostru , așa cum suntem luați serviciul bibliotecii terțe părți. Dar există și alte aspecte care trebuie să fie inversată în cadrul unui program - de exemplu, invocarea de metode și fire pentru a executa cod.

Pentru cei interesați mai detaliat cu privire Inversarea o lucrare de control a fost publicat conturarea unei imagini mai complete a Inversarea de control , ca un model de proiectare (OfficeFloor: folosind modele de birou pentru a îmbunătăți software de proiectare http://doi.acm.org/10.1145/ 2739011.2739013 cu o copie gratuită disponibilă pentru a descărca de la http://www.officefloor.net/mission.html )

Ceea ce este identificat este următoarea relație:

Inversion of Control (metode) = Dependență (stare) de injectare + Continuarea Injection + Injection Subiect

Publicat 29/10/2015 la 04:27
sursa de către utilizator

voturi
7

Programare vorbind

IoC în termeni simpli: Este utilizarea Interface ca mod de ceva anume (un astfel de câmp sau un parametru) ca metacaracter care poate fi folosit de unele clase. Aceasta permite posibilitatea de reutilizare a codului.

De exemplu, să presupunem că avem două clase: Câine și pisică . Ambele împărtășește aceleași calități / prevede: vârsta, mărimea, greutatea. Deci , în loc de a crea o clasă de serviciu numit DogService și CatService , pot crea un singur unul numit AnimalService , care permite utilizarea la câini și pisici numai în cazul în care utilizează interfața IAnimal .

Cu toate acestea, pragmatic vorbind, are ceva înapoi.

a) Cele mai multe dintre dezvoltatorii nu știu cum să - l folosească . De exemplu, pot crea o clasă numită Client și pot crea în mod automat (folosind instrumentele de IDE) o interfață numită ICustomer . Deci, nu este rar pentru a găsi un dosar plin cu clase și interfețe, indiferent dacă interfețele vor fi reutilizate sau nu. Se numește balonat. Unii oameni ar putea argumenta că „ar putea fi , în viitor , am putea folosi“. : - |

b) Are niște limitings. De exemplu, să vorbim despre cazul câine și pisică și vreau să adăugați un nou serviciu (funcționalitate) numai pentru câini. Să presupunem că vreau să calculeze numărul de zile în care am nevoie pentru a instrui un câine ( trainDays()), pentru pisica e inutil, pisicile nu pot fi instruiți (glumesc).

b.1) Dacă am adăuga trainDays()la serviciul AnimalService apoi , de asemenea , funcționează cu pisici și nu este valabil deloc.

b.2) Pot adăuga o condiție în trainDays()cazul în care evaluează care clasa este utilizat. Dar va rupe complet IOC.

b.3) pot crea o nouă clasă de serviciu numit DogService doar pentru noua funcționalitate. Dar, aceasta va crește mentenabilitatii a codului , deoarece vom avea două clase de servicii (cu funcționalități similare) pentru câine și e rău.

Publicat 19/04/2015 la 12:07
sursa de către utilizator

voturi
7

O explicație foarte simplă în scris pot fi găsite aici

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

se spune

„Orice cerere nontrivial este format din două sau mai multe clase care colaborează între ele pentru a efectua unele logica de afaceri. In mod traditional, fiecare obiect este responsabil pentru obținerea propriilor trimiteri la obiectele care colaboreaza (dependențele sale). Atunci când se aplică DI, obiectele sunt date dependențele lor la momentul creării de către o anumită entitate externă care coordonează fiecare obiect din sistem. cu alte cuvinte, dependențe sunt injectate în obiecte.“

Publicat 22/02/2013 la 15:13
sursa de către utilizator

voturi
6

Îmi place această explicație: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Ea începe simplu și prezintă exemple de cod, de asemenea.

introduceți descrierea imaginii aici

Consumatorul, X, are nevoie de clasa consumata, Y, pentru a realiza ceva. Asta e bine și natural, dar are X într-adevăr nevoie să știe că-l folosește Y?

Nu este suficient că X știe că folosește ceva care are comportamentul, metodele, proprietățile etc, din Y, fără să știe cine pune în aplicare de fapt comportamentul?

Prin extragerea o definiție abstractă a comportamentului utilizat de X în Y, așa cum am ilustrat mai jos, și lăsând consumatorului X folosesc o instanță a că, în loc de Y poate continua să facă ceea ce face fără a fi nevoie să cunoască specificul despre Y.

introduceți descrierea imaginii aici

În ilustrația de mai sus Y implementează I și X utilizează o instanță de I. Deși este foarte posibil ca X folosește încă Y ceea ce este interesant este faptul că X nu știe asta. Doar știe că folosește ceva care pune în aplicare I.

Citește articolul pentru informații și descrierea beneficii cum ar fi în continuare:

  • X nu mai este dependentă de Y
  • Mai flexibilă, punerea în aplicare poate fi decisă în timpul rulării
  • Izolarea unității de cod, testare mai ușoară

...

Publicat 16/02/2017 la 02:03
sursa de către utilizator

voturi
4

Inversiune de control este cu privire la transferul controlului de la biblioteca la client. Se face mai mult sens atunci când vorbim despre un client care injecteaza (trece) o valoare de funcție (expresie lambda) într-o mai mare funcție de comandă (funcție de bibliotecă) care controlează (modificări) comportamentul funcției de bibliotecă. Un client sau cadru care injecteaza dependențe bibliotecă (care transportă un comportament) în biblioteci pot fi, de asemenea, luate în considerare IoC

Publicat 24/12/2017 la 18:34
sursa de către utilizator

voturi
4

Am găsit un exemplu foarte clar aici , care explică modul în care „este inversat controla“.

Codul Clasic (fără injecție Dependență)

Iată cum un cod care nu utilizează DI va lucra aproximativ:

  • Aplicație are nevoie de Foo (de exemplu, un controler), astfel:
  • Aplicația creează Foo
  • Aplicație solicită Foo
    • Foo are nevoie de Bar (de exemplu, un serviciu), astfel:
    • Foo creează Bar
    • Foo apeluri Bar
      • Bar are nevoie de Bim (un serviciu, un depozit, ...), astfel:
      • Bar creează Bim
      • Bar face ceva

Utilizarea injecție de dependență

Aici este modul în care un cod, folosind DI va lucra aproximativ:

  • are nevoie de aplicații Foo, care are nevoie de bar, care are nevoie de Bim, astfel:
  • Aplicația creează Bim
  • Aplicația creează Bar și dă-l Bim
  • Aplicația creează Foo și dă-l Bar
  • Aplicație solicită Foo
    • Foo apeluri Bar
      • Bar face ceva

Controlul dependențelor este inversat dintr-o să fie chemat la o chemare.

Ce probleme rezolva?

injecție Dependență îl face ușor de a schimba cu diferite punerea în aplicare a claselor injectate. In timp ce unitate de testare vă puteți injecta o implementare dummy, ceea ce face testarea mult mai ușor.

Ex: Să presupunem că aplicația stochează utilizator fișierul încărcat în Google Drive, cu DI codul controler poate arăta astfel:

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

Atunci când se schimbă cerințele spun, în loc de a vi se cere Disc Google să utilizați Dropbox. Trebuie doar să scrie o implementare dropbox pentru StorageServiceInterface. Nu aveți face orice modificări în controler, atâta timp cât implementarea Dropbox aderă la StorageServiceInterface.

In timp ce testarea vă puteți crea mock pentru StorageServiceInterface cu punerea în aplicare în cazul în care toate dummy metodele de a reveni nule (sau orice valoare predefinită ca pe dvs. cerință de testare).

În schimb , dacă ați avut clasa controller pentru a construi obiectul de stocare cu newcuvântul cheie ca aceasta:

class SomeController
{
    private $storage;

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

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

Când doriți să schimbați cu punerea în aplicare Dropbox trebuie să înlocuiască toate liniile în care newGoogleDriveService obiect este construit și utilizează DropboxService. Pe lângă testarea când clasa SomeController constructorul se așteaptă întotdeauna clasa GoogleDriveService și metodele actuale ale acestei clase sunt declanșate.

Când este cazul și dacă nu? În opinia mea , utilizați DI atunci când crezi că sunt (sau pot exista) implementări alternative ale unei clase.

Publicat 04/11/2017 la 13:27
sursa de către utilizator

voturi
4

Înțeleg că răspunsul a fost deja dat aici. Dar eu încă mai cred că, câteva noțiuni de bază despre inversarea de control trebuie să fie discutate aici, în lungime pentru cititori viitoare.

Inversarea de control (IOC) a fost construit pe un principiu foarte simplu numit Hollywood Principiul . Și se spune că,

Nu ne suna, te vom suna

Ceea ce înseamnă că nu merge la Hollywood pentru a-și îndeplini visul tău, mai degrabă, dacă sunteți demni, atunci Hollywood veți găsi și de a face visul devine realitate. Destul de mult inversat, nu-i asa?

Acum, când vom discuta despre principiul IOC, vom folosi pentru a uita de la Hollywood. Pentru IOC, trebuie să existe trei elemente, un Hollywood, tu și o sarcină ca să-și îndeplinească visul.

În lumea noastră de programare, Hollywood - ul reprezintă un cadru generic (poate fi scris de tine sau de altcineva), reprezintă codul de utilizator ai scris și sarcina reprezintă lucru pe care doriți să realizați cu codul. Acum , nu te duci niciodată pentru a declanșa sarcina dvs. de unul singur, nu în IoC! Mai degrabă ați proiectat totul astfel încât cadru va declanșa sarcina pentru tine. Astfel ați construit un cadru reutilizabil , care poate face pe cineva un erou sau altul un personaj negativ. Dar acest cadru este întotdeauna responsabil, știe când să aleg pe cineva și că cineva știe ce vrea să fie.

Un exemplu din viața reală ar fi dat aici. Să presupunem, doriți să dezvolte o aplicație web. Deci, creați un cadru care se va ocupa de toate lucrurile comune o aplicație web ar trebui să se ocupe ca manipularea cerere http, crearea meniul de aplicatii, care deservesc pagini, gestionarea cookie-urilor, declanșând evenimente etc.

Și apoi lăsați niște cârlige în cadrul dumneavoastră în cazul în care vă puteți pune coduri suplimentare pentru a genera meniuri personalizate, pagini, cookie-uri sau logarea unor evenimente de utilizator, etc. La fiecare cerere browser-ul, cadrul va rula și execută codurile personalizate în cazul cuplat apoi serveste-l înapoi la browser.

Deci, ideea este destul de mult de simplu. Mai degrabă decât a crea o aplicație utilizator care va controla totul, mai întâi creați un cadru reutilizabil, care va controla totul, apoi a scrie codurile personalizate și agățați cadrului pentru a executa cele din timp.

Laravel și EJB sunt exemple de astfel de cadre.

Referinţă:

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

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

Publicat 01/10/2017 la 11:24
sursa de către utilizator

voturi
4

IoC este, de asemenea, cunoscut sub numele de injecție dependență (DI). Este un proces prin care obiectele definesc dependențele lor, adică, celelalte obiecte cu care lucrează, numai prin argumente pentru constructor, argumente la o metodă de fabrică, sau proprietăți care sunt stabilite în instanța de obiect după ce este construită sau întors dintr-o metodă fabrică . Containerul injectează apoi acele dependențe atunci când creează fasole. Acest proces este fundamental invers, de aici numele inversia Control (IOC), a boabelor se controlează instanțierea sau localizarea dependențele sale, prin utilizarea directă construcția de clase, sau un mecanism, cum ar fi modelul de service Locator

Primăvară-cadru-referance.pfd pagina 27 (în cazul în care toate paginile de numărare a documentelor PDF, este în pagina 51)

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

Publicat 24/01/2013 la 15:52
sursa de către utilizator

voturi
3

Inversarea de control este atunci când te duci la magazin și soția ta vă oferă lista de produse pentru a cumpăra.

În termeni de programare a trecut o funcție de apel invers getProductList()la funcția pe care se execută doShopping();

Acesta permite utilizatorului funcției de a defini anumite părți ale acestuia făcându-l mai flexibil.

Publicat 15/12/2017 la 18:35
sursa de către utilizator

voturi
3

Pentru a înțelege conceptul, Inversion de control (IOC) sau Dependență inversiune Principiul (DIP) implică două activități: abstractizare, și inversiune. Injectarea Dependență (DI) este doar una dintre câteva dintre metodele de inversiune.

Pentru a citi mai multe despre acest lucru puteți citi blog - ul meu aici

  1. Ce este?

Este o practică în cazul în care vă lăsați comportamentul real vin din afara limitei (Clasa în Object Oriented Programming). Entitatea de delimitare cunoaște doar abstractia (de exemplu, interfață, clasă abstractă, delegat în Programare orientata pe obiecte) de ea.

  1. Ce probleme rezolva?

În termen de programare, IoC încearcă să rezolve codul monolitic, făcându-l modular, decuplarea diferitelor părți ale acestuia, și să-l unitate-testabile.

  1. Când este cazul și dacă nu?

Este necesar cele mai multe ori, dacă nu aveți situația în care doriți doar codul monolitic (de exemplu, programul foarte simplu)

Publicat 03/06/2016 la 01:46
sursa de către utilizator

voturi
3

Crearea unui obiect din clasa se numește cuplare strânsă, de primăvară elimină această dependență, urmând un model de design (DI / IOC). În care obiectul de clasă în trecut în constructor, mai degrabă decât crearea în clasă. Mai mult vom da super-variabilă de referință în clasa constructor pentru a defini structura mai generală.

Publicat 13/05/2015 la 08:52
sursa de către utilizator

voturi
3
  1. Deci , numărul 1 de mai sus . Ce este Inversarea de control?

  2. Întreținerea este numărul unu lucru pe care-l rezolvă pentru mine. Acesta garantează Sunt folosind interfețe, astfel încât cele două clase nu sunt intim unul cu celălalt.

La utilizarea unui container cum ar fi Castelul Windsor, rezolvă probleme de întreținere chiar mai bine. Fiind capabil de a schimba dintr-o componentă care se duce la o bază de date pentru una care utilizează fișierul de persistență bazat fara a schimba o linie de cod este minunat (schimbare de configurare, ați terminat).

Și odată ce ajunge în generice, devine chiar mai bine. Imaginați-vă că un editor mesaj care primește înregistrări și publică mesaje. Nu-i pasa ce publica, dar are nevoie de un cartograf pentru a lua ceva de la o înregistrare la un mesaj.

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

Am scris-o dată, dar acum pot injecta mai multe tipuri în acest set de cod, dacă pot publica diferite tipuri de mesaje. Pot să scrie, de asemenea, cartografi care să ia o înregistrare de același tip și le vor corespunde cu diferite mesaje. Folosind DI cu Generice mi-a dat posibilitatea de a scrie foarte puțin cod pentru a realiza mai multe sarcini.

Oh, da, există preocupări testabilitate, dar ele sunt secundare beneficiile IoC / DI.

Sunt cu siguranta iubitoare IoC / DI.

3. Devine mai potrivit în momentul în care un proiect de dimensiuni medii de ceva mai mare complexitate. Aș spune că devine necesar în momentul în care începeți să vă simțiți durere.

Publicat 19/09/2008 la 05:59
sursa de către utilizator

voturi
2

Utilizarea IoC nu sunt new'ing sus obiectele. Containerul IoC va face acest lucru și de a gestiona durata de viață a acestora.

Aceasta rezolvă problema de a avea de a schimba manual fiecare instanþierea de un singur tip de obiect la altul.

Este necesar atunci când aveți funcționalitate care ar putea schimba în viitor, sau care pot fi diferite în funcție de mediul sau configurația utilizată în.

Publicat 16/07/2015 la 16:06
sursa de către utilizator

voturi
1

prima versiune de Java EE (J2EE la ora) a introdus conceptul de inversiune a controlului (IOC), ceea ce înseamnă că recipientul ar prelua controlul asupra codului de afaceri și să ofere servicii tehnice (cum ar fi tranzacție sau de management al securității).

Publicat 03/04/2017 la 22:42
sursa de către utilizator

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