Co jest odwrócenie sterowania?

głosy
1k

Inversion of Control (lub IoC) może być dość kłopotliwe, gdy jest pierwszy spotkałem.

  1. Co to jest?
  2. Jakie problemy rozwiązać?
  3. Gdy jest to właściwe i kiedy nie?
Utwórz 06/08/2008 o 04:35
źródło użytkownik
W innych językach...                            


38 odpowiedzi

głosy
1k

Inwersja Kontroli (MKOl) i Dependency Injection (DI) wzory są o usunięcie zależności od kodu.

Na przykład, powiedzmy aplikacja posiada komponent edytora tekstu i chcesz zapewnić sprawdzanie pisowni. Standardowy kod będzie wyglądać następująco:

public class TextEditor {

    private SpellChecker checker;

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

Co zrobiliśmy tutaj tworzy zależność pomiędzy TextEditori SpellChecker. W scenariuszu IoC byśmy zamiast zrobić coś takiego:

public class TextEditor {

    private IocSpellChecker checker;

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

W pierwszym przykładzie kodu jesteśmy instancji SpellChecker( this.checker = new SpellChecker();), co oznacza, że TextEditorklasa zależy bezpośrednio od SpellCheckerklasy.

W drugim przykładzie kodu tworzymy abstrakcję przez posiadające SpellCheckerklasę w zależności TextEditorpodpis konstruktora (nie inicjowanie zależność w klasie). To pozwala nam wywołać uzależnienie następnie przekazać go do klasy TextEditor tak:

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

Teraz klient tworząc TextEditorklasę ma kontrolę nad SpellCheckerrealizacja w użyciu, ponieważ jesteśmy wstrzykiwanie zależności do TextEditorpodpisu.

Jest to tylko prosty przykład, jest to dobry cykl artykułów Simone Busoli że wyjaśnia to bardziej szczegółowo.

Odpowiedział 06/08/2008 o 08:22
źródło użytkownik

głosy
485

Inversion of Control to co masz, gdy callbacks programowe, jak na przykład program GUI.

Na przykład w menu starej szkoły, może być:

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

co pozwala na regulację przepływu interakcji użytkownika.

W programie graficznym lub somesuch, zamiast powiedzieć

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

Więc teraz kontrolować jest odwrócone ... zamiast wejścia użytkownika komputera przyjmując w ustalonej kolejności, użytkownik kontroluje kolejność, w której dane są wpisane, a gdy dane są zapisywane w bazie danych.

Zasadniczo, wszystko z pętli zdarzeń, Callbacki lub wykonać wyzwalacze należy do tej kategorii.

Odpowiedział 06/08/2008 o 06:42
źródło użytkownik

głosy
356

Co jest odwrócenie sterowania?

Jeśli te proste dwa etapy, zrobiliście odwrócenie sterowania:

  1. Oddzielna co -to-zrobić udział od kiedy -to-nie rozłączy.
  2. Upewnić się, że gdy część wie, jak mało jak to możliwe, o jakiej części; i wzajemnie.

Istnieje kilka technik możliwe dla każdej z tych etapów opartych na technologii / języka używanego do realizacji.

-

Inwersja część odwrócenie sterowania (MKOl) jest mylące rzeczą; ponieważ inwersji jest pojęciem względnym. Najlepszym sposobem, aby zrozumieć IoC jest zapomnieć o tym słowie!

-

Przykłady

  • Obsługa zdarzeń. Procedur obsługi zdarzeń (co-to-zrobić część) - Podnoszenie zdarzeń (gdy sytuowanej części)
  • Interfejsów. klient składnik (gdy sytuowanej części) - realizacji komponentu Interface (co-to-zrobić część)
  • xUnit fixure. Konfiguracja i przerywaniem (co-to-zrobić część) - ram xUnit wzywa do instalacji na początku i na końcu przerywaniem (jeśli sytuowanej części)
  • Szablon metoda wzornictwo. Metoda szablon kiedy sytuowanej części - prymitywny wdrożenie podklasy co-to-do udziału
  • DLL metody pojemnik w transmisji. DllMain, DllCanUnload itp (co-to-zrobić część) - COM / OS (gdy do wykonania części)
Odpowiedział 22/07/2010 o 18:34
źródło użytkownik

głosy
81

Inwersja kontroli jest o oddzielenie obawy.

Bez IoC : Masz przenośnego komputera i przypadkowo złamać ekran. I cerować, znaleźć ten sam model laptopa ekran jest nigdzie na rynku. Tak utkniesz.

Z IoC : Masz na pulpicie komputera i przypadkowo złamać ekran. Znaleźć można tylko złapać niemal każdego monitora stacjonarnego z rynku, i to działa dobrze z pulpitu.

Twój pulpit z powodzeniem realizuje IoC w tym przypadku. Akceptuje typ gamy monitorów, podczas gdy laptop nie robi, potrzebuje specjalnego ekranu, aby uzyskać stałe.

Odpowiedział 25/09/2013 o 15:24
źródło użytkownik

głosy
77

Inversion of Control (lub IoC), to jest o uzyskanie wolności (można wziąć ślub, stracił wolność i są kontrolowane. Rozwiedzione, właśnie realizowany odwrócenie sterowania. To, co nazwaliśmy „odłączony”. Dobry system komputerowy zniechęca niektóre bardzo bliskie relacje.) większą elastyczność (kuchnia w biurze służy jedynie czystej wody z kranu, która jest jedynym wyborem, jeśli chcesz do picia. Twój szef realizowane odwrócenie sterowania poprzez utworzenie nowego ekspresu do kawy. teraz można dostać elastyczność wyboru albo wody z kranu lub kawę.) oraz mniejszą zależność (Twój partner ma pracę, nie masz pracy, jesteś finansowo uzależnione od swojego partnera, więc są kontrolowane. znajdziesz pracę, zostały wdrożone Inwersja kontrola. dobry system komputerowy zachęca w zależność).

Podczas korzystania z komputera stacjonarnego, zostały podporządkowane (lub powiedzieć, kontrolowane). Trzeba siedzieć przed ekranem i patrzeć na nią. Korzystanie z klawiatury do pisania i korzystania z myszki, aby poruszać. I źle napisane oprogramowanie może niewolniczej cię jeszcze bardziej. Jeśli zastąpić pulpit z laptopa, a następnie nieco odwrócone kontroli. Można łatwo zabrać go i poruszać. Teraz można kontrolować, gdzie jesteś z komputerem, zamiast komputer go kontroli.

Poprzez wdrożenie odwrócenie sterowania, oprogramowanie / przedmiot konsument uzyskać większą kontrolę nad opcji / Oprogramowanie / obiektów, zamiast być kontrolowane lub posiadające mniej opcji.

Z powyższych idei w umyśle. Nadal brakuje kluczową część MKOl. W scenariuszu IoC, konsument oprogramowanie / przedmiot jest wyrafinowanym ramy. Oznacza to, że został utworzony kod nie jest wywoływana przez siebie. Teraz wyjaśnić, dlaczego w ten sposób działa lepiej dla aplikacji WWW.

Załóżmy, że Twój kod jest grupa pracowników. Muszą zbudować samochód. Pracownicy ci potrzebują miejsca i narzędzie (oprogramowanie) ramy do budowy samochodu. Tradycyjne ramy oprogramowanie będzie jak garaż z wielu narzędzi. Więc robotnicy muszą przygotować plan się i korzystać z narzędzi do budowy samochodu. Budowanie samochodu nie jest łatwy biznes, to będzie bardzo trudne dla pracowników planowanie i współpracują poprawnie. Nowoczesne ramy oprogramowanie będzie jak nowoczesnej fabryki samochodów z wszystkich udogodnień i menedżerów w miejscu. Robotnicy nie trzeba wprowadzać żadnego planu, kierownicy (część ram, są Najlepsi ludzie i sprawił, że najbardziej wyrafinowany plan) pomoże skoordynować tak, że pracownicy wiedzą, kiedy należy wykonywać swoją pracę (ramy zwraca kod). Pracownicy po prostu trzeba być na tyle elastyczne, aby używać żadnych narzędzi menedżerowie dają im (za pomocą Dependency Injection).

Chociaż pracownicy dają kontrolę zarządzania projektem na najwyższym poziomie dla menedżerów (Ramy). Ale to dobrze, że niektórzy specjaliści pomóc. Jest to pojęcie IoC naprawdę pochodzą.

Nowoczesne aplikacje internetowe z architektury MVC zależy od ram zrobić URL Routing i umieścić w miejscu dla kontrolerów ramach zadzwonić.

Dependency Injection i odwrócenie sterowania są powiązane. Dependency Injection jest w mikro poziomie i odwrócenie sterowania jest w makro poziomie. Trzeba jeść każdy kęs (wdrożenie DI) w celu zakończenia posiłku (wdrożenie MKOl).

Odpowiedział 04/03/2013 o 20:33
źródło użytkownik

głosy
72

Przed użyciem odwrócenie sterowania należy zdawać sobie sprawę z faktu, że ma swoje wady i zalety i należy wiedzieć, dlaczego go używać, jeśli to zrobisz.

Plusy:

  • Twój kod zostanie odłączona, dzięki czemu można łatwo wymieniać implementacje interfejsu z alternatywnych implementacji
  • Jest silny motywator dla kodowania przeciwko interfejsów zamiast implementacji
  • To bardzo proste, aby pisać testy jednostkowe w kodzie, ponieważ zależy od niczego innego niż to akceptuje obiektów w jego konstruktora / ustawiaczy i można łatwo zainicjować je z odpowiednimi obiektami w izolacji.

Cons:

  • IoC odwraca nie tylko przepływ sterowania w programie, ale również zaciemnia go znacznie. Oznacza to, że można nie tylko odczytać kod i skakać z jednego miejsca do drugiego, ponieważ połączenia, które normalnie byłyby w kodzie nie są już w kodzie. Zamiast tego jest w plikach konfiguracyjnych XML lub adnotacje w kodzie swojej kontenera IoC, które interpretuje te metadane.
  • Powstaje nowa klasa robaków, gdzie zdobycie config XML lub adnotacje źle i można spędzić dużo czasu dowiedzieć się, dlaczego Twój kontener IoC wstrzykuje null odniesienie do jednego z obiektów w określonych warunkach.

Osobiście widzę mocne strony MKOl i ja naprawdę je lubię, ale staram się unikać IoC gdy jest to możliwe, ponieważ okazuje swoje oprogramowanie do zbioru klas, które nie stanowią już „prawdziwy” program, ale po prostu coś, co musi zostać połączone przez konfiguracja metadanych XML lub adnotacji i spadnie (i spada) od siebie bez niego.

Odpowiedział 12/02/2010 o 15:31
źródło użytkownik

głosy
55
  1. Artykuł Wikipedii . Dla mnie odwrócenie sterowania obraca swoją kolejno kod napisany i przekształcając go w strukturę delegacji. Zamiast programu wyraźnie kontrolującego wszystko, program tworzy klasę lub biblioteki z niektórych funkcji, które można nazwać, gdy pewne rzeczy się zdarzają.

  2. To rozwiązuje powielania kodu. Na przykład, w dawnych czasach byś ręcznie napisać własną pętlę zdarzeń, przeszukiwania bibliotek systemowych dla nowych wydarzeń. Obecnie większość nowoczesnych API wystarczy powiedzieć bibliotek systemowych, jakie zdarzenia, które Cię interesują, a będzie ci znać, kiedy wydarzy.

  3. Odwrócenie sterowania jest praktycznym sposobem na zmniejszenie powielania kodu, a jeśli okaże się, kopiując całą metodę i zmienia tylko mały kawałek kodu, można rozważyć rozwiązywaniu jej odwrócenie sterowania. Odwrócenie sterowania jest łatwy w wielu językach przez pojęcia delegatów, interfejsów, lub nawet surowych wskaźników funkcji.

    To nie jest odpowiedni do stosowania we wszystkich przypadkach, ponieważ przepływ programu mogą być trudniejsze do naśladowania kiedy napisany w ten sposób. Jest to użyteczny sposób projektowania metod podczas pisania biblioteki, które będą ponownie wykorzystane, ale powinno być stosowane oszczędnie w rdzeniu własnego programu, chyba że naprawdę rozwiązuje problem powielania kodu.

Odpowiedział 06/08/2008 o 05:33
źródło użytkownik

głosy
38

Ale myślę, że trzeba być bardzo ostrożnym z nim. Jeśli będzie nadużywać tego wzorca, można zrobić bardzo skomplikowaną konstrukcję i jeszcze bardziej skomplikowany kod.

Podobnie jak w tym przykładzie z TextEditor: jeśli masz tylko jeden pisowni może tak naprawdę nie jest niezbędne do korzystania z IoC? Chyba, że ​​trzeba pisać testy jednostkowe czy coś ...

Tak czy inaczej: być rozsądny. Wzorzec projektowania są dobre praktyki , ale nie Biblia być głoszona. Nie trzymać go wszędzie.

Odpowiedział 06/08/2008 o 23:08
źródło użytkownik

głosy
34

Załóżmy, że jesteś obiektem. I udać się do restauracji:

Bez IoC : poprosić o „jabłko”, a ty zawsze służył jabłko kiedy pytasz więcej.

Z IoC : Można prosić o „owocu”. Można dostać różnych owoców każdorazowo Ci służył. przykładowo, jabłko, pomarańcza, lub arbuza.

Tak, oczywiście, IoC jest korzystne, gdy chcesz odmian.

Odpowiedział 25/09/2013 o 15:00
źródło użytkownik

głosy
34

IoC / DI do mnie pcha się zależnościami do powołania obiektów. Super proste.

Odpowiedź non-techniczny jest w stanie zamienić się silnik w samochodzie tuż przed włącz go. Jeśli wszystko zahacza prawej (interface) są dobre.

Odpowiedział 19/09/2008 o 03:54
źródło użytkownik

głosy
23
  1. Inwersji sterowania jest wzór służy do rozdzielenia komponentów i warstwy w systemie. Wzór jest realizowane poprzez wstrzykiwanie zależności do składnika, gdy jest on skonstruowany. Zależności te są zazwyczaj dostarczane jako interfejsy dla dalszego oddzielenia i wspierać testowalności. kontenery IoC / DI takich jak Zamek Windsor, Jedności są narzędzia (biblioteki), które mogą być wykorzystane do zapewnienia MKOl. Narzędzia te zapewniają rozszerzone funkcje wykraczające poza proste zarządzanie zależnościami, w tym życiu, AOP / Przechwytywanie, polityka itd

  2. za. Łagodzi komponent z bycia odpowiedzialnym za zarządzanie jego zależności.
    b. Umożliwia implementacje zależnościami zamienią się w różnych środowiskach.
    do. Pozwala to elementem badane przez drwi zależności.
    re. Zapewnia mechanizm udostępniania zasobów w całej aplikacji.

  3. za. Krytyczne robiąc Test-Driven Development. Bez IoC może być trudne, aby sprawdzić, ponieważ składniki testowane są silnie połączony z resztą systemu.
    b. Krytyczne przy opracowywaniu systemów modułowych. Modułowy system jest systemem, którego elementy mogą być wymieniane bez konieczności ponownej kompilacji.
    do. Krytyczny, jeśli istnieje wiele obaw przekrojowe, które powinny zająć, partilarly w aplikacji korporacyjnej.

Odpowiedział 19/09/2008 o 03:27
źródło użytkownik

głosy
17

będę spisywać moje proste zrozumienie tych dwóch kategoriach:

For quick understanding just read examples*

Wstrzyknięcie zależność (DI):
Zależność wtryskowo, na ogół oznacza przekazanie obiektu, w którym sposób polega, jako parametr sposobu, zamiast sposób utworzenia obiektu zależnego .
Co to oznacza w praktyce, że metoda nie zależy bezpośrednio od konkretnej realizacji; każdy realizacja spełniający wymagania mogą być przekazywane jako parametr.

Dzięki temu obiekty powiedzieć thier zależności. A wiosna sprawia, że jest dostępna.
Prowadzi to do luźno rozwój aplikacji.

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

Odwrócenie sterowania (MKOl) w opakowaniu:
Jest to wspólna cecha ram, MKOl zarządza obiekty Java
- od instancji do zniszczenia poprzez BeanFactory.
-java elementy, które są tworzone wystąpienia przez kontener IoC nazywane są fasola, a kontener IoC zarządza zakres fasoli, wydarzeń cyklu życia, a także wszelkie funkcje AOP dla którego został skonfigurowany i zakodowane.

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,

Poprzez wdrożenie odwrócenie sterowania, oprogramowanie / przedmiot konsument uzyskać większą kontrolę nad opcji / Oprogramowanie / obiektów, zamiast być kontrolowane lub posiadające mniej opcji.

Odwrócenie sterowania jako wytyczne projektowania służy do następujących celów:

Jest oddzielenie wykonanie pewnego zadania z realizacji.
Każdy moduł może skupić się na tym, co jest ona przeznaczona dla.
Moduły sprawiają żadnych założeń co zrobić inne systemy, ale opierają się na umowach.
Wymiana modułów ma efekt uboczny w innych modułach
będę trzymać rzeczy abstrakcyjne tutaj, można odwiedzić następujące linki do szczegółów zrozumienia tematu.
Dobry przykład z odczytu

Szczegółowe wyjaśnienie

Odpowiedział 10/11/2014 o 08:43
źródło użytkownik

głosy
15

Na przykład, zadanie nr 1 jest stworzenie obiektu. MKOl bez koncepcji, zadanie nr 1 ma być wykonywana przez Programmer.But Z MKOl koncepcji, zadanie nr 1 będzie wykonywana przez pojemniku.

W skrócie Kontrola zostaje odwrócona od programatora do pojemnika. Tak, to jest nazywane jako odwrócenie sterowania.

Znalazłem jeden dobry przykład tutaj .

Odpowiedział 27/01/2010 o 13:15
źródło użytkownik

głosy
14

Odbieranie tylko pierwszej części. Co to jest?

Inwersji sterowania (COI), służące do tworzenia przykłady zależności między pierwszym i drugim przypadku z grupy (ewentualnie wstrzykując je przez konstruktora), zamiast tworzenia instancji klasy, a potem wystąpienie klasa tworzenia przykłady zależności. Tak więc odwrócenie sterowania odwraca się przepływ sterowania programem. Zamiast z odbierającym kontrolującego ten przepływ sterowania (podczas tworzenia zależnościami), przy czym rozmówca kontroluje przepływ kontroli programu .

Odpowiedział 11/01/2016 o 00:49
źródło użytkownik

głosy
14

Wydaje się, że najbardziej mylące rzeczą „IoC” akronimem i nazwy na której stoi jest to, że zbyt efektowne nazwy - prawie nazwą hałasu.

Czy naprawdę potrzebny jest nazwa, pod którą opisać różnicę między programowania proceduralnego i zdarzeniami? OK, jeśli trzeba, ale nie musimy wybrać nową markę „większa niż życie” nazwa, która myli więcej niż rozwiązuje?

Odpowiedział 19/01/2011 o 04:50
źródło użytkownik

głosy
13

Pozwól, aby powiedzieć, że robimy jakieś spotkanie w jakimś hotelu.

Wielu ludzi, wiele karafki wody, wiele plastikowe kubki.

Kiedy ktoś chce pić, ona wypełnić filiżanka, napój i wyrzucić kubek na podłodze.

Po godzinie czy coś mamy podłoga pokryta plastikowych kubków i wody.

Niech kontrolę inwertowanego.

To samo spotkanie w tym samym miejscu, ale zamiast plastikowych kubków mamy kelner z jednym szklane (Singleton)

a ona cały czas oferuje gościom pitnej.

Kiedy ktoś chce pić, ona dostać od kelner szkła, pić i odesłać go z powrotem do kelnera.

Pomijając kwestię higienicznych, ostatnia forma kontroli procesowej pitnej jest o wiele bardziej skuteczny i ekonomiczny.

I to jest dokładnie to, co Wiosna (inny kontener IoC, na przykład: Guice) robi. Zamiast let do tworzenia aplikacji, co potrzebne przy użyciu nowego słowa kluczowego (biorąc plastikowy kubek), Spring IoC kontenera wszystkie oferty czasu do zastosowania samo wystąpienie (singleton) potrzebnego obiektu (szklanką wody).

Myśleć o sobie jako organizator tego zgromadzenia. Musisz drogę wiadomość do administracji hotelu

Członkowie spotkanie będzie potrzebować szklankę wody, ale nie bułka z masłem.

Przykład:-

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

}

Przydatne linki:-

Odpowiedział 26/09/2012 o 18:54
źródło użytkownik

głosy
13

Zgadzam się z NilObject , ale chciałbym dodać do tego:

jeśli okaże się, kopiując całą metodę i zmienia tylko mały kawałek kodu, można rozważyć rozwiązywaniu jej odwrócenie sterowania

Jeśli znajdziesz się skopiowanie i wklejenie kodu wokół, jesteś prawie zawsze robi coś złego. Skodyfikowane jako zasady projektowania raz i tylko raz .

Odpowiedział 06/08/2008 o 06:20
źródło użytkownik

głosy
10

MKOl o odwrócenie relacji między kodu i kodu strony trzeciej (biblioteka / ramowej):

  • W normalnych s / w rozwoju, piszesz main () metody i wywołać metody „biblioteki”. Ci są pod kontrolą :)
  • W IoC „Ramy” kontroluje main () i wywołuje swoje metody. Ramowa jest pod kontrolą :(

DI (Dependency Injection) jest o tym, jak przepływa kontroli w aplikacji. Tradycyjna aplikacja miała przepływ sterowania z aplikacji (metoda main ()) do innych wywołań metod biblioteka, ale przepływ sterowania DI jest odwrócony to ramy zajmuje rozpoczynając swoją aplikację, inicjalizacji i powołując swoje metody na każde żądanie.

W końcu zawsze wygrać :)

Odpowiedział 19/09/2014 o 19:25
źródło użytkownik

głosy
7

Odwrócenie sterowania jest zasadą rodzajowy, a Dependency Injection realizuje tę zasadę jako wzorzec projektowej dla budowy wykresu obiektu (tj kontroli konfiguracyjnych jak obiekty są odwołującego się nawzajem, zamiast samego obiektu kontrolnego, jak uzyskać odwołanie do innego obiektu).

Patrząc na odwrócenie sterowania jako wzorzec projektowania, musimy spojrzeć na to, co mamy odwrócenie. Dependency Injection odwraca kontrolę budowy wykres obiektów. Jeśli powiedziano w perspektywie laika, odwrócenie sterowania implikuje zmianę przepływu sterowania w programie. Na przykład. W tradycyjnej aplikacji autonomicznej, mamy metodę główne, z którym kontrola zostanie przekazana do innych bibliotek stron trzecich (w przypadku użyliśmy funkcji biblioteki strony trzeciej), ale poprzez odwrócenie sterowania sterowania zostanie przeniesiony z kodem biblioteki strony trzeciej do naszego kodu jak bierzemy usługę biblioteki osób trzecich. Ale są też inne aspekty, które muszą być odwrócone w ramach programu - np wywołanie metod i nici do wykonania kodu.

Dla zainteresowanych bardziej szczegółowo na odwrócenie sterowania dokument został opublikowany przedstawiając pełniejszy obraz odwrócenie sterowania jako wzorca projektowego (OfficeFloor: stosując wzory biurowych w celu poprawy projektowania oprogramowania http://doi.acm.org/10.1145/ 2739011.2739013 z bezpłatną kopię można pobrać z http://www.officefloor.net/mission.html )

Co jest identyfikowany jest następująca zależność:

Odwrócenie sterowania (metody) = Zależność (stan) wtryskowe + kontynuacja Wtrysk Wtrysk + wątku

Odpowiedział 29/10/2015 o 04:27
źródło użytkownik

głosy
7

Programowanie speaking

IoC w dogodnych warunkach: To wykorzystanie interfejsu jako sposób konkretnego czegoś takiego pola (lub parametrów) jako zamiennika, które mogą być wykorzystywane przez niektórych klas. Umożliwia on ponownego wykorzystania kodu.

Na przykład, powiedzmy, że mamy dwie klasy: Pies i Kot . Zarówno dzieli te same właściwości / stwierdza: wiek, rozmiar, wagę. Więc zamiast tworzyć klasy usługi o nazwie DogService i CatService mogę utworzyć pojedynczy jeden o nazwie AnimalService pozwalającą na korzystanie z psów i kotów wyłącznie wtedy, gdy użycie interfejsu IAnimal .

Jednak pragmatycznie rzecz biorąc, ma pewne tyłu.

a) Większość deweloperów nie wiem, jak go używać . Na przykład, można utworzyć klasę o nazwie klienta i mogę tworzyć automatycznie (za pomocą narzędzia IDE) interfejs o nazwie ICustomer . Tak, to nie jest rzadkością, aby znaleźć folder wypełniony klas i interfejsów, nie ważne czy interfejsy zostaną ponownie wykorzystane lub nie. To się nazywa nadęty. Niektórzy ludzie mogą twierdzić, że „może być w przyszłości mogli go użyć”. : - |

b) Ma pewne limitings. Na przykład, pomówmy o przypadku psów i kotów i chcę dodać nową usługę (funkcjonalność) tylko dla psów. Załóżmy, że chcę, aby obliczyć liczbę dni, że muszę trenować psa ( trainDays()), dla kota to bezużyteczne, koty nie mogą być przeszkoleni (żartuję).

B.1) Jeśli dodać trainDays()do serwisu AnimalService to działa również z kotami i nie jest ważne w ogóle.

B.2) Mogę dodać warunek w trainDays()którym ocenia, która klasa jest używana. Ale będzie to całkowicie złamać MKOl.

B.3) można utworzyć nową klasę usługi nazywane DogService tylko dla nowej funkcjonalności. Ale będzie to wzrost konserwacji kodu, ponieważ będziemy mieć dwie klasy usług (o podobnej funkcjonalności) dla psów i to jest złe.

Odpowiedział 19/04/2015 o 12:07
źródło użytkownik

głosy
7

Bardzo prosty napisany wyjaśnienie można znaleźć tutaj

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

to mówi

„Każdy nietrywialna aplikacja składa się z dwóch lub większej liczby klas, które współpracują ze sobą, aby wykonać jakąś logikę biznesową. Tradycyjnie, każdy obiekt jest odpowiedzialny za uzyskanie własnych odniesień do obiektów Współpracuje z (jego zależnościami). Przy stosowaniu DI się obiekty są podane ich zależności w momencie tworzenia przez jakiegoś zewnętrznego podmiotu, który koordynuje każdy obiekt w systemie. innymi słowy, zależności są wstrzykiwane do obiektów „.

Odpowiedział 22/02/2013 o 15:13
źródło użytkownik

głosy
6

Lubię to wyjaśnienie: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

To początek prosty i pokazuje przykłady kodu, jak również.

wprowadzić opis obrazu tutaj

Konsument, X, potrzebuje zużywanej klasę, Y, aby coś osiągnąć. To wszystko, co dobre i naturalne, ale nie X naprawdę trzeba wiedzieć, że używa Y?

Czy nie wystarczy, że X wie, że wykorzystuje coś, co ma zachowanie, metody, właściwości itp, Y, nie wiedząc, kto faktycznie realizuje zachowanie?

Przez ekstrakcję abstrakcyjnej definicji zachowania używanej przez X w Y, przedstawionej jako I poniżej, i pozwolić konsument X użyć instancji, że zamiast Y może nadal robić to, co robi, bez konieczności znajomości specyfiki o Y.

wprowadzić opis obrazu tutaj

Na ilustracji powyżej Y implementuje I i X korzysta z instancji I. Choć jest to całkiem możliwe, że nadal używa X Y co ciekawe jest to, że X nie wiemy. To po prostu wie, że korzysta z czegoś, który implementuje I.

Przeczytaj artykuł dla dalszych informacji oraz opis korzyści, takich jak:

  • X nie jest już zależny od Y
  • Bardziej elastyczny, realizacja może zostać podjęta w czasie wykonywania
  • Izolowanie zespołu kodów, łatwiejsze badanie

...

Odpowiedział 16/02/2017 o 02:03
źródło użytkownik

głosy
4

Odwrócenie sterowania wynosi około przekazywania sterowania z biblioteki do klienta. To sprawia, że ​​więcej sensu, gdy mówimy o klienta, który wstrzykuje (przechodzi) wartość funkcji (wyrażenie lambda) do funkcja wyższego rzędu (funkcja Library), który steruje (zmianami) zachowanie funkcji biblioteki. Klient lub ramy, które wstrzykuje zależności Library (zachowanie), które prowadzą do bibliotek można również uznać IoC

Odpowiedział 24/12/2017 o 18:34
źródło użytkownik

głosy
4

Znalazłem bardzo wyraźny przykład tutaj co wyjaśnia, w jaki sposób „kontrola jest odwrócony”.

Kod klasyczny (bez wstrzyknięcia zależność)

Oto jak kod nie używając DI będzie grubsza działa:

  • Aplikacja musi Foo (np Controller), więc:
  • Aplikacja tworzy Foo
  • Aplikacja nazywa Foo
    • Foo potrzebuje bar (np usługa), więc:
    • Foo Bar tworzy
    • Foo Bar nazywa
      • Bar potrzebuje Bim (usługę, repozytorium, ...), więc:
      • Bar tworzy Bim
      • Bar robi coś

Przy użyciu iniekcji zależnościach

Oto, w jaki sposób za pomocą kodu DI będzie grubsza działa:

  • Foo potrzebuje aplikacja, która potrzebuje Bar, który potrzebuje Bim, więc:
  • Aplikacja tworzy Bim
  • Aplikacja tworzy bar i nadaje mu Bim
  • Aplikacja tworzy Foo i nadaje mu Bar
  • Aplikacja nazywa Foo
    • Foo Bar nazywa
      • Bar robi coś

Sterowanie zależnościami jest odwrócone od siebie są wezwani do jednej powołania.

Jakie problemy rozwiązać?

wtrysk zależność sprawia, że ​​łatwo zamienić z innym realizacji wstrzyknięto klas. Podczas testów jednostkowych można wstrzykiwać obojętne wdrożenia, co sprawia, że ​​testowanie dużo łatwiejsze.

Przykład: Załóżmy, że aplikacja przechowuje przesłanego pliku użytkownika w Google Drive, z DI kod kontroler może wyglądać następująco:

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

Gdy wymagania zmieniają się powiedzieć, zamiast Dysk Google zostaniesz poproszony używać Dropbox. Wystarczy tylko napisać implementację skrzynki domyślnej dla StorageServiceInterface. Nie trzeba wprowadzać żadnych zmian w kontrolerze ile realizacja Dropbox przylega do StorageServiceInterface.

Podczas testowania można tworzyć makiety dla StorageServiceInterface z manekina realizacji gdzie wszystkie metody zwróci null (lub predefiniowanych wartości jak na swoje wymagania testowania).

Zamiast tego, jeśli miał klasę kontrolera na budowę obiektu z pamięci newsłów kluczowych takich jak to:

class SomeController
{
    private $storage;

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

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

Gdy chcesz zmienić z realizacją Dropbox trzeba wymienić wszystkie linie gdzie newobiekt GoogleDriveService jest skonstruowany i używają DropboxService. Poza tym podczas testowania klasy SomeController konstruktor zawsze oczekuje klasa GoogleDriveService i rzeczywiste metody tej klasy są wywoływane.

Gdy jest to właściwe i kiedy nie? Moim zdaniem użyć DI kiedy myślisz, że są (lub mogą istnieć) alternatywne implementacje klasy.

Odpowiedział 04/11/2017 o 13:27
źródło użytkownik

głosy
4

Rozumiem, że odpowiedź została już podana tutaj. Ale nadal uważam, pewne podstawy o odwrócenie sterowania muszą być omówione tutaj w długości dla przyszłych czytelników.

Inversion of Control (IoC) został zbudowany na bardzo prostej zasadzie zwanej Hollywood Zasada . I mówi, że

Nie zadzwonić do nas, będziemy Ci zadzwonić

Co to znaczy, że nie idą do Hollywood, aby spełniać swoje marzenia, a jeśli jesteś godny następnie Hollywood znajdzie cię i twoje marzenie się spełni. Dość dużo odwrócony, co?

Teraz, kiedy dyskutujemy o zasady IoC, używamy zapomnieć o Hollywood. Dla IoC, nie musi być trzech elementów, Hollywood, ty i zadanie jak spełnić swoje marzenia.

W naszym świecie programowania, Hollywood stanowią ogólne ramy (może być napisany przez ciebie lub kogoś innego), Państwo reprezentują kod użytkownika, który napisał i zadanie reprezentowania rzeczą, którą chcesz osiągnąć w kodzie. Teraz nie zawsze iść do uruchomienia zadania samodzielnie, a nie w IoC! Raczej zostały zaprojektowane w taki sposób, że wszystko twoja ramy wyzwoli zadanie dla Ciebie. W ten sposób stworzyliśmy ramy wielokrotnego użytku, które mogą sprawić, że ktoś się bohaterem lub inny czarny charakter. Ale że ramy jest zawsze odpowiedzialny za to wie, kiedy należy wybrać kogoś i że ktoś wie, co chce być.

Prawdziwy przykład życie będzie podana tutaj. Załóżmy, że chcesz stworzyć aplikację internetową. Więc stworzenie ram, które będą obsługiwać wszystkie wspólne rzeczy aplikacja internetowa powinna obsłużyć jak obsługi żądania HTTP, tworzenie menu aplikacji, obsługujących strony, zarządzania plikami cookie, wyzwalanie zdarzeń itd.

A następnie pozostawić pewne haczyki w swojej ramach której można umieścić dodatkowe kody do generowania menu niestandardowego, stron, ciasteczek lub zalogowaniu pewne zdarzenia użytkownika itd. Na każde żądanie przeglądarki Twój ramowa zostanie i wykonuje swoje kody niestandardowe jeśli zaczepione następnie służyć go z powrotem do przeglądarki.

Tak, pomysł jest dość dużo prosty. Zamiast tworzenia aplikacji użytkownika, który będzie kontrolować wszystko, najpierw stworzyć ramy wielokrotnego użytku, które będą kontrolować wszystko potem napisać swoje własne kody i podłączyć go do ram do wykonywania tych w czasie.

Laravel i EJB są przykłady takich struktur.

Odniesienie:

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

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

Odpowiedział 01/10/2017 o 11:24
źródło użytkownik

głosy
4

IoC jest również znany jako iniekcję zależności (DI). Jest to proces, w którym obiekty określenia ich zależności, to znaczy, że inne przedmioty, z którymi pracują tylko przez argumenty konstruktora argumentów sposobu fabrycznego lub właściwości, które są ustawione na przykład obiektu po jego skonstruowane lub zwracane z metody fabryki , Pojemnik następnie wstrzykuje te zależności, gdy tworzy Bean. Proces ten jest zasadniczo odwrotne, stąd nazwa odwrócenie sterowania (COI), bobu samej sterującego instancji lub miejsce jej zależności za pomocą bezpośredniego budowę klas, albo też, na przykład w postaci wzoru usługi lokalizatora

Spring-framework-referance.pfd strona 27 (jeśli liczyć wszystkie strony dokumentu PDF, to na stronie 51)

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

Odpowiedział 24/01/2013 o 15:52
źródło użytkownik

głosy
3

Odwrócenie sterowania jest, gdy idziesz do sklepu i żona daje listę produktów do kupienia.

Pod względem programowania mijała funkcję zwrotną getProductList()do funkcji, którą są wykonującego doShopping();

To pozwala użytkownikowi funkcji, aby zdefiniować pewne jego części dzięki czemu jest bardziej elastyczny.

Odpowiedział 15/12/2017 o 18:35
źródło użytkownik

głosy
3

Do zrozumienia koncepcji, Inversion of Control (IOC) lub Dependency Inversion Principle (DIP) obejmuje dwa rodzaje działalności: abstrakcja, i inwersję. Zastrzyk zależność (DI) to tylko jedna z nielicznych metod inwersji.

Aby dowiedzieć się więcej na ten temat można przeczytać mój blog tutaj

  1. Co to jest?

Jest to praktyka, gdzie niech rzeczywiste zachowanie pochodzą z zewnętrznej granicy (klasa w Object Oriented Programming). Podmiot granica wie tylko abstrakcję (np interfejs, klasa abstrakcyjna, delegat w Object Oriented Programming) z niego.

  1. Jakie problemy rozwiązać?

W perspektywie programowania IoC spróbować rozwiązać kod monolityczny, czyniąc go modułowy, oddzielenie różnych części tego, i sprawiają, że jednostka-sprawdzalne.

  1. Gdy jest to właściwe i kiedy nie?

Wskazane jest przez większość czasu, chyba że masz sytuację, w której chcesz tylko kod monolityczny (np bardzo prosty program)

Odpowiedział 03/06/2016 o 01:46
źródło użytkownik

głosy
3

Tworzenie obiektu w klasie nazywa mocno sprzęgło, Wiosna usuwa tę zależność stosując wzorzec projektowania (DI / IOC). W którym przedmiot klasie przeszedł w konstruktorze, zamiast tworzenia w klasie. Więcej na damy super-zmienną referencyjną konstruktora klasy w celu zdefiniowania bardziej ogólną strukturę.

Odpowiedział 13/05/2015 o 08:52
źródło użytkownik

głosy
3
  1. Więc liczba 1 powyżej . Co jest odwrócenie sterowania?

  2. Konserwacja jest numerem jeden rzeczą dla mnie to rozwiązuje. Gwarantuje to używam interfejsów tak, że dwie klasy nie są ze sobą intymny.

W użyciu pojemnika jak Zamek Windsor, rozwiązuje problemy konserwacji nawet lepiej. Będąc w stanie zamienić się składnik, który trafia do bazy danych dla jednego, który używa wytrwałości w oparciu plików bez zmiany linii kodu jest niesamowite (zmiana konfiguracji, skończysz).

A gdy dojdziesz do leków generycznych, to staje się jeszcze lepszy. Wyobraź sobie, że wydawca otrzymuje wiadomość rekordy i publikuje wiadomości. Nie obchodzi mnie to, co publikuje, ale to wymaga mapowania wziąć coś od rekordu do wiadomości.

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

Napisałem go raz, ale teraz mogę wstrzyknąć do wielu rodzajów tego zestawu kodu gdybym publikować różne rodzaje komunikatów. Mogę również napisać twórców map, które mają zapis tego samego typu i odwzorować je do różnych komunikatów. Korzystanie z DI rodzajowych dał mi możliwość pisania bardzo mało kodu do wykonania wiele zadań.

Oh yeah, istnieją obawy sprawdzalności, ale są one wtórne w stosunku do korzyści wynikających z IoC / DI.

Ja na pewno kochający IoC / DI.

3. Staje się to bardziej właściwe w chwili masz średniej wielkości projekt nieco większej złożoności. Chciałbym powiedzieć, że staje się to stosowne, minuty zaczniesz uczucie bólu.

Odpowiedział 19/09/2008 o 05:59
źródło użytkownik

głosy
2

Korzystanie IoC nie są new'ing swoje obiekty. Kontener IoC będzie zrobić i zarządzać żywotność nich.

To rozwiązuje problem konieczności ręcznej zmiany wszelkich konkretyzacji jednego typu obiektu do drugiego.

Wskazane jest, gdy masz funkcje, które mogą ulec zmianie w przyszłości lub które mogą się różnić w zależności od środowiska lub konfiguracji stosowanej w.

Odpowiedział 16/07/2015 o 16:06
źródło użytkownik

głosy
1

Czytałem wiele odpowiedzi na to, ale jeśli ktoś jest nadal mylone i potrzebuje plus ultra „laymans termin” wyjaśnić IoC tutaj jest moje zdanie:

Wyobraźmy sobie rodzice i dzieci rozmawiają ze sobą.

Bez IoC:

* Nadrzędna : Można tylko mówić, kiedy zadać pytania i można działać tylko kiedy daję wam pozwolenie.

Rodzic : To znaczy, że nie może mnie zapytać, czy można jeść, bawić się iść do łazienki lub nawet spać, jeśli nie poprosi.

Rodzic : Chcesz jeść?

Dziecko : Nie.

Rodzic : Dobra, będę z powrotem. Zaczekaj na mnie.

Dziecko : (chce grać, ale ponieważ nie ma wątpliwości, od rodzica, dziecko nie może nic zrobić).

Po upływie 1 godziny...

Rodzic : Jestem z powrotem. Chcesz zagrać?

Dziecko : Tak.

Rodzic : Zezwolenie udzielone.

Dziecko : (wreszcie jest w stanie grać).

Ten prosty scenariusz wyjaśnia kontrola koncentruje się na rodzica. Wolność dziecka jest ograniczony i bardzo zależy na pytania rodziców. Dziecko może tylko mówić pytany mówić, a może tylko działać, gdy pozwolenie.

Z IoC:

Dziecko ma teraz możliwość zadawania pytań i rodzic może reagować z odpowiedziami i uprawnień. Oznacza po prostu kontrola jest odwrócony! Dziecko jest teraz do zadawania pytań w każdej chwili i choć wciąż jest zależnościami z rodzicem odnośnie uprawnień, nie jest zależne od środków mówienia / zadawania pytań.

W sposób techniczny wyjaśnienia, jest bardzo podobny do konsoli / otoczka / cmd vs interakcji GUI. (Który jest odpowiedzią Mark Harrison powyżej no.2 górnym odpowiedź). W konsoli, to są zależne od tego, co jest proszony / wyświetlane na ciebie i nie można przejść do innych menu i funkcji, nie odpowiadając, że to pierwsze pytanie; po ściśle strumienia sekwencyjnego. (programowego jest jak metody / pętli funkcji). Jednak z GUI, menu i funkcje są określone, a użytkownik może wybrać, co musi więc mają więcej kontroli i są mniej ograniczone. (programowo menu mają zwrotnego po wybraniu i wykonania czynności).

Odpowiedział 07/08/2019 o 02:45
źródło użytkownik

głosy
1

Pierwsza wersja Java EE (J2EE w czasie) wprowadził pojęcie odwrócenie sterowania (MKOl), co oznacza, że ​​pojemnik będzie przejąć kontrolę nad swoim kodem gospodarczej i świadczenia usług technicznych (takich jak transakcji lub zarządzanie bezpieczeństwem).

Odpowiedział 03/04/2017 o 22:42
źródło użytkownik

głosy
0

Skoro już istnieje wiele odpowiedzi na pytanie, ale żaden z nich nie przedstawia podział terminu Inversion Kontroli widzę szansę, aby dać odpowiedź bardziej zwięzły i użyteczne.

Odwrócenie sterowania jest wzór, który implementuje Zasada Inwersja Dependency (DIP). DIP następujące stany: 1. Moduły wysokiego szczebla nie powinno zależeć od modułów niskopoziomowych. Zarówno powinien zależeć abstrakcji (np interfejsy). 2. Abstractions nie powinna zależeć od szczegółów. Szczegóły (konkretne implementacje) powinna zależeć od abstrakcji.

Istnieją trzy rodzaje odwrócenie sterowania:

Interfejs inwersyjne dostawcy nie powinni zdefiniować interfejs. Zamiast tego, konsument powinien zdefiniować interfejs i dostawcy muszą go wdrożyć. Interfejs umożliwia Inversion eliminując konieczność modyfikowania konsumentowi za każdym razem, gdy nowy dostawca dodał.

Przepływ inwersyjne Changes kontrolę przepływu. Na przykład, masz aplikację konsoli, gdzie poproszony o wpisanie wielu parametrów i po każdym wpisany parametr jesteś zmuszony nacisnąć Enter. Można zastosować Przepływ Inwersja tutaj i wdrożyć aplikację na pulpicie, w którym użytkownik może wybrać kolejność wprowadzania parametrów, użytkownik może zmieniać parametry, a na ostatnim etapie, użytkownik musi nacisnąć Enter tylko raz.

Inwersja stworzenie To może być realizowane za pomocą następujących wzorów: Wzór Factory, lokalizatora usług i Dependency Injection. Stworzenie Inversion pomaga wyeliminować zależności między typami ruchu proces tworzenia obiektów poza zależnością od rodzaju, który wykorzystuje te zależnościami obiektów. Dlaczego zależności są złe? Oto kilka przykładów: bezpośredni utworzenie nowego obiektu w kodzie ułatwia testowanie trudniejsze; to jest niemożliwe, aby zmienić odniesienia w zespołach bez rekompilacji (OCP naruszenie zasady); nie można łatwo zastąpić desktop UI za pomocą internetowego interfejsu użytkownika.

Odpowiedział 12/08/2019 o 18:36
źródło użytkownik

głosy
0

Naprawdę nie rozumiejąc, dlaczego istnieje wiele błędnych odpowiedzi, a nawet akceptowane jest nie dość dokładne tworzenie rzeczy trudne do zrozumienia. Prawda jest zawsze prosta i czysta.

Jak @Schneider skomentował w odpowiedzi @Mark Harrisona , proszę po prostu czytać posta Martin Fowler za omawianie MKOl.

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

Jednym z najbardziej kocham to:

Zjawisko to jest odwrócenie sterowania (znany również jako Hollywood Principle - „Nie do nas zadzwonić, będziemy cię nazywają”).

Czemu?

Wiki dla IoC , mogę zacytować fragment.

Odwrócenie sterowania służy do zwiększania modułowość programu i uczynić go rozszerzalny ... wtedy dodatkowo spopularyzowana w 2004 roku przez Roberta C. Martin i Martin Fowler .

Robert C. Martin: autor <<Clean Code: A Handbook of Agile Software Craftsmanship>>.

Martin Fowler: autor <<Refactoring: Improving the Design of Existing Code>>.

Odpowiedział 09/05/2019 o 03:39
źródło użytkownik

głosy
0

Aby zrozumieć IoC, powinniśmy mówić o Dependency Inversion.

Zależność Inwersja: Zależy od abstrakcji, a nie na konkrecji.

Odwrócenie sterowania: Main vs abstrakcji, jak i główny jest klej systemów.

DIP i IoC

Są jakieś dobre posty rozmawiają na ten temat:

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/

Odpowiedział 13/04/2019 o 14:58
źródło użytkownik

głosy
0

Co to jest? Inwersja (sprzęganie) sterujących zmienia kierunek sprzęgania z sygnatury metody. Ze sterowaniem odwróconym definicja podpisu metoda jest podyktowane przez wdrożenie metody (zamiast rozmówcy metody). O pełne wyjaśnienie

Jakim problemem to rozwiązać? Z góry na dół sprzęgło o metodach. To z kolei eliminuje konieczność refaktoryzacji.

Gdy jest to właściwe wykorzystanie, a kiedy nie? Dla małych ściśle określonych zastosowań, które nie są przedmiotem wielu zmian, jest prawdopodobne, narzut. Jednakże, w przypadku mniej określonych zastosowań, które ewoluują, zmniejsza wrodzoną sprzęgło podpisu metody. Daje to większą swobodę deweloperów rozwijać aplikację, unikając konieczności wykonania kosztownych refaktoryzacji kodu. Zasadniczo, umożliwia aplikację zmianie wraz z małym przeróbek.

Odpowiedział 28/02/2019 o 17:37
źródło użytkownik

głosy
0

Oznacza odwrócenie sterowania można kontrolować w jaki sposób elementy (klasy) zachowują. Dlaczego jego nazwie „inwersja”, ponieważ przed tym wzorem zajęcia były twarde przewodowy i były ostateczne, co będą robić np

importowania biblioteki, która posiada TextEditori SpellCheckerklas. Teraz oczywiście to SpellCheckerbędzie tylko sprawdzić pisownię dla języka angielskiego. Załóżmy, że jeśli chcesz, TextEditoraby obsłużyć języka niemieckiego i być w stanie sprawdzić pisownię masz nad nim kontroli.

z IoC ta kontrola jest odwrócony czyli jej wam, w jaki sposób? biblioteka będzie zaimplementować coś takiego:

Będzie ona mieć TextEditorklasę, a następnie będzie mieć ISpeallChecker(który jest interfejsem zamiast beton SpellCheckerklasy) i podczas konfigurowania rzeczy w IoC kontenera np wiosną można podać własną implementację „ISpellChecker”, który będzie sprawdzał pisownię dla języka niemieckiego. więc kontrola jak sprawdzanie pisowni będzie działać jest ineverted pochodzi z tej biblioteki i wam. Ów MKOl.

Odpowiedział 14/02/2019 o 23:03
źródło użytkownik

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