Co to jest Inwersja sterowania?

Inwersja sterowania jest tym, co dostajesz, gdy twój program oddzwania, np. jak program gui.

Na przykład w starym menu szkoły możesz mieć:

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

W programie GUI lub jakimś innym, zamiast tego mówimy:

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 kontrola jest odwrócona... zamiast komputera przyjmującego dane użytkownika w ustalonej kolejności, użytkownik kontroluje kolejność wprowadzania danych, a gdy dane są zapisywane w baza danych.

Zasadniczo wszystko, co zawiera pętlę zdarzeń, wywołania zwrotne lub wyzwalacze execute, należy do tej kategorii.

Co to jest Inwersja sterowania?

Jeśli wykonasz te dwa proste kroki, wykonasz inwersję Sterowania:

1. oddziel co -to-do part od Kiedy -to-do part.
2. Upewnij się, że Kiedy część zna jakomało Jak to możliwe ojaka część; i odwrotnie.

Istnieje kilka technik możliwych dla każdego z tych kroków w oparciu o technologię / język, którego używasz wdrożenie.

--

inwersja część inwersji sterowania (IOC) jest myląca, ponieważ inwersja jest pojęciem względnym. Najlepszym sposobem na zrozumienie MKOl jest zapomnienie o tym słowie!

--

Przykłady

• Obsługa Zdarzeń. Event Handlers (what-to-do part) -- Raising Events (when-to-do part)
• Interfejsy. Component client (when-to-do part) -- implementacja interfejsu komponentu (what-to-do część)
• xUnit fixure. Konfiguracja i TearDown (what-to-do part) -- struktury xUnit wywołują Setup na początku i TearDown na końcu (when-to-do part)
• wzór wzoru metody szablonowej. metoda szablonu where-to-do part -- prymitywna implementacja podklasy what-to-do part
• Metody kontenerów DLL w COM. DllMain, DllCanUnload, etc (what-to-do part) -- COM/OS (when-to-do part)

Inwersja kontrolek polega na rozdzielaniu obaw.

Bez IoC: Masz laptop komputer i przypadkowo złamiesz ekran. I kurczę, znajdziesz ten sam model ekranu laptopa nie ma nigdzie na rynku. Więc utknąłeś.

Z IoC: Masz pulpit komputer i przypadkowo złamać ekran. Możesz po prostu chwycić prawie każdy monitor stacjonarny z rynku i działa dobrze z pulpitem.

Twój desktop z powodzeniem wdraża IoC w tym przypadku. Akceptuje różnego rodzaju monitory, podczas gdy laptop nie, potrzebuje określonego ekranu, aby go naprawić.

Inwersja kontroli, (lub IoC), jest o uzyskanie wolności (bierzesz ślub, straciłeś wolność i jesteś kontrolowany. Rozwiodłeś się, właśnie wprowadziłeś inwersję kontroli. Tak się nazywaliśmy, "odsprzęgnięty". Dobry system komputerowy zniechęca do bardzo bliskich relacji.) większa elastyczność (kuchnia w Twoim biurze serwuje tylko czystą wodę z kranu, to twój jedyny wybór, gdy chcesz się napić. Twój szef zaimplementował inwersję sterowania, ustawiając nowy ekspres do kawy. Teraz masz elastyczność wyboru wody z kranu lub kawy.) i mniej zależności (twój partner ma pracę, ty nie masz pracy, jesteś zależny finansowo od partnera, więc jesteś kontrolowany. Znajdziesz pracę, zaimplementowałeś inwersję sterowania. Dobry system komputerowy zachęca do uzależnienia.)

Kiedy używasz komputera stacjonarnego, masz niewolnika (lub powiedzmy, kontrolowanego). Musisz usiąść przed ekranem i spojrzeć na niego. Używanie klawiatury do pisania i używania mysz do nawigacji. A źle napisane oprogramowanie może cię jeszcze bardziej zniewolić. Jeśli zastąpisz komputer stacjonarny laptopem, to nieco odwrócona Kontrola. Możesz go łatwo wziąć i poruszać się. Więc teraz możesz kontrolować, gdzie jesteś za pomocą swojego komputera, zamiast komputera, który go kontroluje.

Implementując inwersję sterowania, użytkownik oprogramowania / obiektu otrzymuje więcej kontroli / opcji nad oprogramowaniem / obiektami, zamiast być kontrolowanym lub mieć mniej opcji.

Z ponad ideami w umyśle. Wciąż brakuje nam kluczowej części MKOl. W scenariuszu IoC konsument oprogramowania / obiektu jest wyrafinowanym frameworkiem. Oznacza to, że utworzony kod nie jest wywoływany samodzielnie. Teraz wyjaśnijmy, dlaczego ten sposób działa lepiej dla aplikacji webowej.

Załóżmy, że Twój kod to grupa pracowników. Muszą zbudować samochód. Ci pracownicy potrzebują miejsca i narzędzi (framework oprogramowania) do budowy samochodu. tradycyjny Framework oprogramowania będzie jak garaż z wieloma narzędzia. Pracownicy muszą więc sami opracować plan i użyć narzędzi do budowy samochodu. Budowa samochodu nie jest łatwym biznesem, pracownikom będzie naprawdę ciężko zaplanować i prawidłowo współpracować. nowoczesny framework oprogramowania będzie jak nowoczesna fabryka samochodów z wszystkimi udogodnieniami i menedżerami na miejscu. Pracownicy nie muszą tworzyć żadnego planu, menedżerowie (część ram, są najmądrzejszymi ludźmi i zrobili najbardziej wyrafinowany plan) pomogą koordynować tak, aby pracownicy wiedzą, kiedy wykonywać swoją pracę(framework nazywa Twój kod). Pracownicy muszą tylko być na tyle elastyczni, aby korzystać z narzędzi, które dają im menedżerowie (poprzez zastrzyk zależności).

Chociaż pracownicy dają kontrolę nad zarządzaniem projektem na najwyższym poziomie menedżerom (ramy). Ale dobrze jest mieć kilku specjalistów pomóc. Z tego właśnie wywodzi się koncepcja MKOl.

Nowoczesne aplikacje internetowe z architekturą MVC zależą od frameworka do zrobienia URL Routingu i umieścić Kontrolery w celu wywołania frameworka.

Iniekcja zależności i Inwersja sterowania są ze sobą powiązane. Iniekcja zależności jest na poziomie mikro, A Inwersja sterowania jest na poziomie makro. Musisz jeść każdy kęs (zaimplementuj DI), aby zakończyć posiłek (zaimplementuj IoC).

Przed użyciem inwersji sterowania należy dobrze zdawać sobie sprawę z tego, że ma ona swoje plusy i minusy i powinieneś wiedzieć, dlaczego go używasz, jeśli to robisz.

Plusy:

• Twój kod zostanie oddzielony, dzięki czemu możesz łatwo wymienić implementacje interfejsu z alternatywnymi implementacjami
• jest silnym motywatorem do kodowania na interfejsach zamiast implementacji
• bardzo łatwo jest napisać testy jednostkowe dla Twojego kodu, ponieważ zależy to od niczego innego niż obiekty, które akceptuje w swoim konstruktorze / ustawiaczach i można je łatwo zainicjować odpowiednimi obiektami w izolacji.

Wady:

• IoC nie tylko odwraca przepływ sterowania w programie, ale także znacznie go zaciemnia. Oznacza to, że nie możesz już po prostu czytać kodu i przeskakiwać z jednego miejsca do drugiego, ponieważ połączenia, które normalnie byłyby w Twoim kodzie, nie są już w kodzie. Zamiast tego jest w plikach konfiguracyjnych XML lub adnotacjach oraz w kodzie kontener IoC, który interpretuje te metadane.
• pojawia się nowa klasa błędów, w której błędna jest konfiguracja XML lub adnotacje i możesz poświęcić dużo czasu na dowiedzenie się, dlaczego kontener IoC wstrzykuje odwołanie null do jednego z Twoich obiektów pod pewnymi warunkami.

Osobiście widzę mocne strony IoC I naprawdę je lubię, ale staram się unikać IoC, gdy tylko jest to możliwe, ponieważ zmienia to twoje oprogramowanie w kolekcję klas, które nie są już stanowić "prawdziwy" program, ale po prostu coś, co musi być połączone przez konfigurację XML lub metadane adnotacji i rozpadłby się (i upadł) bez niego.

1. Artykuł Wikipedii . Dla mnie inwersja kontroli to przekształcenie twojego sekwencyjnie napisanego kodu i przekształcenie go w strukturę delegacji. Zamiast jawnie kontrolować wszystko, twój program tworzy klasę lub bibliotekę z określonymi funkcjami, które będą wywoływane, gdy pewne rzeczy się wydarzą.

2. Rozwiązuje powielanie kodu. Na przykład w dawnych czasach ręcznie zapisywałeś własną pętlę zdarzeń, sprawdzając biblioteki systemowe pod kątem nowych zdarzeń. W dzisiejszych czasach, większość nowoczesnych API po prostu powiedzieć bibliotekom systemowym, jakie wydarzenia jesteś zainteresowany, i to poinformuje cię, kiedy One się wydarzy.

3. Odwrócenie sterowania jest praktycznym sposobem na ograniczenie duplikacji kodu, a jeśli kopiujesz całą metodę i zmieniasz tylko mały fragment kodu, możesz rozważyć rozwiązanie tego problemu z odwróceniem sterowania. Inwersja sterowania jest łatwa w wielu językach dzięki koncepcji delegatów, interfejsów, a nawet surowych Wskaźniki funkcji.

   Nie jest właściwe, aby używać w każdym przypadku, ponieważ przepływ programu może być trudniejszy do naśladowania, gdy jest napisany w ten sposób. Jest to przydatny sposób projektowania metod podczas pisania biblioteki, która będzie ponownie używana, ale powinna być używana oszczędnie w rdzeniu własnego programu, chyba że naprawdę rozwiązuje problem duplikacji kodu.

Ale myślę, że musisz być z tym bardzo ostrożny. Jeśli nadużywasz tego wzoru, zrobisz bardzo skomplikowany projekt i jeszcze bardziej skomplikowany kod.

Jak w tym przykładzie z TextEditor: jeśli masz tylko jeden Sprawdzacz pisowni, może nie jest konieczne używanie IoC ? Chyba, że musisz napisać testy jednostkowe ...

W każdym razie: bądź rozsądny. Wzorce konstrukcyjne To dobre praktyki , ale nie Biblia, którą należy głosić. Nie przyklejaj go wszędzie.

Przypuśćmy, że jesteś obiektem. I idziesz do restauracji:

Bez IoC : prosisz o "jabłko", a zawsze podaje się jabłko, gdy prosisz o więcej.

Z IoC : możesz poprosić o "owoce". Za każdym razem możesz dostać różne owoce. na przykład jabłko, pomarańcza lub melon wodny.

Więc, oczywiście, IoC jest preferowane, gdy lubisz odmiany.

IoC / DI dla mnie wypycha zależności do wywołujących obiektów. Bardzo proste.

Nietechniczną odpowiedzią jest możliwość wymiany silnika w samochodzie tuż przed włączeniem. Jeśli wszystko się zgadza (interfejs), jesteś dobry.

1. Inwersja sterowania jest wzorem używanym do odsprzęgania elementów i warstw w systemie. Wzorzec jest zaimplementowany poprzez wstrzykiwanie zależności do komponentu, gdy jest on skonstruowany. Zależności te są zwykle dostarczane jako interfejsy do dalszego odsprzęgania i wspierania testowalności. Kontenery IoC / DI takie jak Castle Windsor, Unity są narzędziami (bibliotekami), które mogą być wykorzystane do zapewnienia IoC. Narzędzia te zapewniają rozszerzone funkcje wykraczające poza proste zależności zarządzanie, w tym dożywotnie, AOP / Przechwytywanie, polityka itp.

2. A. zwalnia komponent z odpowiedzialności za zarządzanie jego zależnościami.
   b. zapewnia możliwość zamiany implementacji zależności w różnych środowiskach.
   C. umożliwia testowanie komponentu poprzez wyśmiewanie zależności.
   D. zapewnia mechanizm udostępniania zasobów w całej aplikacji.

3. A. krytyczne podczas testowania rozwoju. Bez MKOl może być trudne do przetestowania, ponieważ badane komponenty są silnie sprzężone z resztą systemu.
   B. krytyczne przy opracowywaniu systemów modułowych. System modułowy to system, którego elementy można wymienić bez konieczności rekompilacji.
   C. krytyczne, jeśli istnieje wiele przekrojowych problemów, które należy rozwiązać, partilarly w aplikacji korporacyjnej.

Zapiszę moje proste zrozumienie tych dwóch terminów:

For quick understanding just read examples*

Dependency Injection (DI):
Iniekcja zależności (Dependency injection) zazwyczaj oznacza przekazanie obiektu, od którego zależy metoda, jako parametr do metody, zamiast tworzenia obiektu zależnego .
w praktyce oznacza to, że metoda nie zależy bezpośrednio od konkretnej implementacji; każda implementacja spełniająca wymagania może być przekazana jako parametr.

z tym obiektów powiedzieć thier zależności. A wiosna go udostępnia.
prowadzi to do luźno powiązanego rozwoju aplikacji.

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

Inversion of Control(IoC) Container:
Jest to powszechna cecha frameworków, IOC zarządza obiektami java
– od powstania do zniszczenia poprzez swoją fabrykę fasoli.
-komponenty Java, które są tworzone przez kontener IoC nazywane są beans, a kontener IOC zarządzanie zakresem fasoli, zdarzeniami cyklu życia i wszystkimi funkcjami AOP, dla których została skonfigurowana i zakodowana.

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.

Implementując inwersję sterowania, użytkownik oprogramowania / obiektu otrzymuje więcej kontroli / opcji nad oprogramowaniem / obiektami, zamiast być kontrolowanym lub mieć mniej opcji.

Inwersja sterowania jako wytyczne projektowe służy następującym celom:

Istnieje oddzielenie wykonania określonego zadania od wdrożenie.
Każdy moduł może skupić się na tym, do czego jest przeznaczony.
Moduły nie mają żadnych założeń co do tego, co robią inne systemy, ale opierają się na swoich kontraktach.
Wymiana modułów nie ma wpływu ubocznego na inne moduły
będę trzymać rzeczy streszczenie tutaj, można odwiedzić następujące linki do szczegółowego zrozumienia tematu.
dobra lektura z przykładem

Szczegółowe wyjaśnienie

Odpowiadam tylko na pierwszą część. O co chodzi?

Inversion of Control (IOC) oznacza tworzenie instancji zależności pierwszej i drugiej instancji klasy (opcjonalnie wstrzykiwanie ich przez konstruktor), zamiast tworzenia instancji klasy pierwszej, a następnie instancji klasy tworzącej instancje zależności. W ten sposób inwersja sterowania odwraca przepływ sterowania programu. zamiast callee kontrolujący przepływ control (podczas tworzenia zależności), wywołujący kontroluje przepływ sterowania programem.

Na przykład zadanie#1 polega na wytworzeniu obiektu. Bez IOC concept Zadanie#1 ma być wykonane przez programistę.Ale z IOC concept, Zadanie#1 będzie wykonywane przez kontener.

W skrócie sterowanie jest odwrócone od programatora do kontenera. Tak więc nazywa się to inwersją sterowania.

Znalazłem jeden dobry przykład tutaj .

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

Jeśli okaże się, że skopiujesz całą metodę i zmienisz tylko mały fragment kodu, możesz rozważyć rozwiązanie tego problemu z odwróceniem sterowania

Jeśli znajdziesz się w kopiowaniu i wklejaniu kodu, prawie zawsze robisz coś źle. Skodyfikowany jako zasada projektowania raz i tylko raz .

Wydaje się, że najbardziej mylące w " IoC " akronim i nazwa, dla której on stoi, jest to, że jest zbyt efektowna nazwa-prawie nazwa szumu.

Czy naprawdę potrzebujemy nazwy, by opisać różnicę między programowaniem proceduralnym a programowaniem sterowanym zdarzeniami? OK, jeśli musimy, ale czy musimy wybrać nową nazwę" bigger than life", która bardziej myli niż rozwiązuje?

Powiedzmy, że spotkamy się w jakimś hotelu.

Po godzinie czy coś mamy podłogę pokrytą plastikowymi kubkami i wodą.

Odwróć sterowanie.

To samo spotkanie w tym samym miejscu, ale zamiast plastikowych kubków mamy kelnera z jednym szklanym kubkiem (Singleton)

I ona cały czas oferuje do goście piją.

I właśnie to robi Spring (inny kontener IoC, na przykład: Guice). Zamiast pozwolić aplikacji stworzyć to, czego potrzebuje, używając nowego słowa kluczowego (biorąc plastikowy kubek), Spring IoC container all of time oferuje aplikację ta sama instancja (singleton) potrzebnego obiektu (szklanka wody).

Członkowie spotkania będą potrzebowali szklanki wody, ale nie bułki 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:-

• http://adfjsf.blogspot.in/2008/05/inversion-of-control.html
• http://martinfowler.com/articles/injection.html
• http://www.shawn-barrett.com/blog/post/Tip-of-the-day-e28093-Inversion-Of-Control.aspx

IoC polega na odwróceniu relacji między Twoim kodem a kodem strony trzeciej (biblioteka/framework):

• w normalnym rozwoju s / w, piszesz główna() method i wywołanie metod "library". Ty są pod kontrolą:)
• w IoC" framework " controls główna() i nazywa swoje metody. Na ramy jest pod kontrolą: (

DI (Dependency Injection) jest o tym, jak kontrola płynie w podanie. Tradycyjna aplikacja desktopowa miała przepływ sterowania z aplikacji (metoda main ()) do innych wywołań metod bibliotecznych, ale z DI przepływ sterowania jest odwrócony, że ' s framework zajmuje się uruchamianiem aplikacji, inicjalizowaniem jej i wywoływaniem metod w razie potrzeby.

W końcu zawsze wygrywasz:)

Znalazłem bardzo jasny przykład tutaj, który wyjaśnia jak 'kontrola jest odwrócona'.

Klasyczny kod (bez iniekcji zależności)

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

• Aplikacja potrzebuje Foo( np. kontrolera), więc:
• Aplikacja tworzy Foo
• aplikacja wywołuje Foo
  • Foo potrzebuje paska (np. usługi), więc:
  • Foo tworzy pasek
  • Foo calls Bar
    • Bar potrzebuje Bim (usługa, repozytorium,...), więc:
    • Bar tworzy Bim
    • Bar robi coś

Using dependency injection

Oto jak będzie działać kod z DI:

• Aplikacja potrzebuje Foo, który potrzebuje Bar, który potrzebuje Bim, więc:
• Aplikacja tworzy Bim
• Aplikacja tworzy pasek i nadaje mu Bim
• Aplikacja tworzy Foo i nadaje mu pasek
• wywołania aplikacji Foo
  • Foo calls Bar
    • Bar robi coś

Kontrola zależności jest odwrócona od jednego wywołania do jednego wywołania.

Jakie problemy rozwiązuje?

Dependency injection ułatwia zamianę z różnymi implementacjami wtryskiwanych klas. Podczas testowania jednostkowego można wprowadzić atrapę implementacji, co znacznie ułatwia testowanie.

Ex: Załóżmy, że aplikacja przechowuje plik przesłany przez użytkownika na Dysku Google, z DI Twój kod kontrolera może wyglądać tak:

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 twoje wymagania się zmienią, zamiast GoogleDrive zostaniesz poproszony o Korzystanie z Dropbox. Wystarczy tylko napisać implementację dropbox dla StorageServiceInterface. Nie musisz wprowadzać żadnych zmian w kontrolerze, o ile implementacja Dropbox jest zgodna z usługą StorageServiceInterface.

Podczas testowania można stworzyć makietę dla StorageServiceInterface z implementacją atrapy, gdzie wszystkie metody zwracają null(lub dowolną predefiniowaną wartość zgodnie z wymaganiami testowymi).

Zamiast tego, jeśli posiadasz klasę kontrolera do konstruowania obiektu storage ze słowem kluczowym new w następujący sposób:

class SomeController
{
    private $storage;

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

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

Jeśli chcesz zmienić implementację Dropbox, musisz zastąpić wszystkie linie, w których zbudowany jest obiekt GoogleDriveService i użyć DropboxService. Poza tym podczas testowania klasy SomeController konstruktor zawsze oczekuje klasy GoogleDriveService i uruchamiane są rzeczywiste metody tej klasy.

Kiedy jest to właściwe, a kiedy nie? Moim zdaniem używasz DI, gdy myślisz ,że istnieją (lub mogą istnieć) alternatywne implementacje klasy.

Odwrócenie kontroli jest wtedy, gdy idziesz do sklepu spożywczego, a twoja żona daje Ci listę produktów do zakupu.

W kategoriach programowych przekazywała funkcję zwrotną getProductList() do funkcji, którą wykonujesz doShopping();

Pozwala użytkownikowi funkcji definiować niektóre jej części, czyniąc ją bardziej elastyczną.

Bardzo proste pisemne wyjaśnienie można znaleźć tutaj

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

Mówi

" każda aplikacja nietrywialna składa się z dwóch lub więcej klas, które współpracuj ze sobą, aby wykonać logikę biznesową. Tradycyjnie każdy obiekt jest odpowiedzialny za uzyskanie własnego odniesienia do obiektów, z którymi współpracuje (jego zależności). Podczas stosowania DI obiekty są biorąc pod uwagę ich zależności przy tworzeniu czasu przez jakiś zewnętrzny byt koordynujący każdy obiekt w system. Innymi słowy, zależności są wstrzykiwane do obiektów."

Programowanie mówienie

IoC w prostych słowach: jest to użycie interfejsu jako sposobu określonego czegoś (takiego pola lub parametru) jako symbolu wieloznacznego, który może być używany przez niektóre klasy. Pozwala na ponowne wykorzystanie kodu.

Na przykład, powiedzmy, że mamy dwie klasy: pies iKot . Oba mają te same cechy/Stany: wiek, rozmiar, waga. Więc zamiast tworzyć klasę usług o nazwie DogService i CatService , mogę utworzyć pojedynczy o nazwie AnimalService , który pozwala na korzystanie z psa i Kota tylko wtedy, gdy korzystają z interfejsu IAnimal.

Jednak, pragmatycznie rzecz biorąc, ma trochę wstecz.

A) większość programistów nie wie, jak z niego korzystać . Na przykład, mogę utworzyć klasę o nazwie Customer i mogę utworzyć automatycznie (używając narzędzi IDE) interfejs o nazwie ICustomer. Nierzadko zdarza się więc znaleźć folder wypełniony klasami i interfejsy, bez względu na to, czy interfejsy będą ponownie używane, czy nie. Nazywa się wzdęty. Niektórzy ludzie mogliby argumentować, że "może być w przyszłości możemy go użyć". :-|

B. 1) jeśli dodam trainDays() do Serwisu AnimalService to działa również z kotami i w ogóle nie jest ważny.

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

B. 3) mogę utworzyć nową klasę usług o nazwie DogService tylko dla nowej funkcjonalności. Ale zwiększy to konserwowalność kodu, ponieważ będziemy mieli dwie klasy usług (o podobnej funkcjonalności) dla psa i jest źle.

Inwersja sterowania jest ogólną zasadą, podczas gdy iniekcja zależności realizuje tę zasadę jako wzorzec projektowy dla konstrukcji grafu obiektowego (tzn. konfiguracja kontroluje, jak Obiekty się odwołują, a nie sam obiekt kontroluje, jak uzyskać odniesienie do innego obiektu).

Patrząc na inwersję sterowania jako wzorzec projektowy, musimy spojrzeć na to, co odwracamy. Dependency Injection odwraca kontrolę nad konstruowaniem wykresu obiektów. Jeśli w terminologii laika, inwersja sterowania oznacza zmianę w przepływie sterowania w programie. Np. W tradycyjnej samodzielnej aplikacji mamy główną metodę, skąd kontrola jest przekazywana do innych bibliotek stron trzecich( w przypadku, gdy użyliśmy funkcji biblioteki stron trzecich), ale poprzez odwrócenie kontroli kontrola jest przenoszona z kodu biblioteki stron trzecich do naszego kodu, ponieważ korzystamy z usługi biblioteki stron trzecich. Ale są inne aspekty, które muszą być odwrócone w programie - np. wywołanie metod i wątków do wykonania kodu.

Dla osób zainteresowanych głębszą tematyką inwersji sterowania opublikowano artykuł przedstawiający pełniejszy obraz inwersji sterowania jako wzorca projektowego (OfficeFloor: using office patterns to improve software design http://doi.acm.org/10.1145/2739011.2739013 z darmową kopią dostępną do pobrania z http://www.officefloor.net/mission.html )

Wyróżnia się następujące relacja:

Inwersja Sterowania (dla metod) = zależność (stan) Wtrysk + Wtrysk kontynuacyjny + Wtrysk wątku

Podoba mi się to Wyjaśnienie: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Zaczyna się prosto i pokazuje również przykłady kodu.

Konsument, X, potrzebuje konsumowanej klasy, Y, aby coś osiągnąć. To wszystko jest dobre i naturalne, ale czy X naprawdę musi wiedzieć, że używa Y?

Czy nie wystarczy, że X wie, że używa czegoś, co ma zachowanie, metody, właściwości itp. nie wiedząc, kto faktycznie realizuje to zachowanie?

Wyodrębniając abstrakcyjną definicję zachowania używanego przez x W y, zilustrowaną jak poniżej, i pozwalając konsumentowi X używać instancji tego zamiast Y, może nadal robić to, co robi bez konieczności znajomości specyfiki Y.

Na powyższej ilustracji y implementuje i, A X używa instancji I. chociaż jest całkiem możliwe, że X nadal używa Y, co ciekawe, X nie wiedz o tym. Po prostu wie, że używa czegoś, co implementuje I.

Przeczytaj artykuł, aby uzyskać więcej informacji i opis korzyści, takich jak:

• X nie jest już zależne od Y
[27]} bardziej elastyczny, o implementacji można decydować w runtime
• Izolacja jednostki kodu, łatwiejsze testowanie

...

Rozumiem, że odpowiedź już tu została udzielona. Nadal jednak myślę, że niektóre podstawy o inwersji sterowania muszą być omówione tutaj obszernie dla przyszłych czytelników.

Inwersja sterowania (IoC) została zbudowana na bardzo prostej zasadzie zwanej zasadą Hollywood . I mówi, że

Don 't call us, we' ll call you

To znaczy, że nie jedź do Hollywood, aby spełnić swoje marzenie, a jeśli jesteś godny, to Hollywood odnajdzie cię i spełni Twoje marzenie. Całkiem odwrócony, co?

Teraz, gdy dyskutujemy o zasadzie MKOl, zapominamy o Hollywood. Dla MKOl muszą być trzy elementy: Hollywood, Ty i zadanie, które spełni Twoje marzenie.

W naszym świecie programowania, Hollywood reprezentuje ogólny framework (może być napisany przez Ciebie lub kogoś innego), ty reprezentujesz kod użytkownika, który napisałeś, aZadanie reprezentuje rzecz, którą chcesz / align = "left" / Teraz nigdy nie idziesz, aby uruchomić swoje zadanie samodzielnie, nie w MKOl! Raczej zaprojektowałeś wszystko w taki sposób, że Twoja struktura uruchomi Twoje zadanie. W ten sposób zbudowałeś framework wielokrotnego użytku, który może uczynić kogoś bohaterem lub innym złoczyńcą. Ale ten framework zawsze rządzi, wie, kiedy kogoś wybrać i że ktoś wie tylko, czym chce być.

Przykład z prawdziwego życia byłby tutaj podany. Załóżmy, że chcesz rozwijać sieć podanie. Tworzysz więc framework, który będzie obsługiwał wszystkie typowe rzeczy, które powinna obsługiwać aplikacja internetowa, takie jak obsługa żądania http, tworzenie menu aplikacji, serwowanie stron, Zarządzanie plikami cookie, wyzwalanie zdarzeń itp.

A następnie zostawiasz Hooki w swoim frameworku, gdzie możesz umieścić kolejne kody do generowania niestandardowego menu, stron, plików cookie lub rejestrowania niektórych zdarzeń użytkownika itp. Na każde żądanie przeglądarki Twój framework uruchomi się i wykona Twoje niestandardowe kody, jeśli go podłączysz, a następnie wyśle go z powrotem do przeglądarki.

Więc pomysł jest dość prosty. Zamiast tworzyć aplikację użytkownika, która będzie kontrolować wszystko, najpierw tworzysz framework wielokrotnego użytku, który będzie kontrolować wszystko, a następnie piszesz własne kody i zaczepiasz je do frameworku, aby wykonać je w czasie.

Laravel i EJB to przykłady takiego ramy.

Odniesienie:

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

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

Inwersja sterowania polega na przeniesieniu sterowania z biblioteki do klienta. Ma to większy sens, gdy mówimy o kliencie, który wstrzykuje (przekazuje) wartość funkcji (wyrażenie lambda) do funkcji wyższego rzędu (funkcja biblioteczna), która kontroluje (zmienia) zachowanie funkcji bibliotecznej. Klient lub framework, który wprowadza zależności bibliotek (które przenoszą zachowanie) do bibliotek, może być również uważany za IoC

1. Więc numer 1 powyżej. Co to jest Inwersja sterowania?

2. Konserwacja to dla mnie najważniejsze rozwiązanie. To gwarantuje, że używam interfejsów tak, że dwie klasy nie są ze sobą intymne.

Używając kontenera takiego jak Castle Windsor, rozwiązuje problemy konserwacyjne jeszcze lepiej. Możliwość zamiany komponentu, który trafia do bazy danych na komponent wykorzystujący trwałość opartą na plikach bez zmiany linii kodu jest awesome (zmiana konfiguracji, gotowe).

A kiedy już zaczniesz brać leki generyczne, będzie jeszcze lepiej. Wyobraź sobie, że wydawca wiadomości otrzymuje rekordy i publikuje wiadomości. Nie obchodzi go, co publikuje, ale potrzebuje mapera, który przeniesie coś z rekordu do wiadomości.

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

Napisałem go kiedyś, ale teraz mogę wprowadzić wiele typów do tego zestawu kodu, jeśli opublikuję różne typy wiadomości. Mogę również pisać mapery, które biorą rekord tego samego typu i mapy je do różnych wiadomości. Używanie DI z generykami dało mi możliwość napisania bardzo mało kodu, aby wykonać wiele zadań.

O tak, istnieją problemy z testowalnością, ale są one drugorzędne w stosunku do zalet IoC/DI.

Zdecydowanie kocham IoC / DI.

3 . Staje się bardziej odpowiedni w momencie, gdy masz średniej wielkości projekt o nieco większej złożoności. Powiedziałbym, że jest to właściwe, gdy tylko zaczniesz odczuwać ból.

Tworzenie obiektu wewnątrz klasy nazywa się tight coupling, Spring usuwa tę zależność poprzez zastosowanie wzorca projektowego (DI / IOC). W którym obiekcie klasy w przekazywane w konstruktorze zamiast tworzenia w klasie. Więcej nad dajemy super class Reference variable w konstruktorze, aby zdefiniować bardziej ogólną strukturę.

Aby zrozumieć to pojęcie, Inwersja sterowania (IoC) lub zasada inwersji zależności (DIP) obejmuje dwie czynności: abstrakcję i inwersję. Iniekcja zależności (Di) jest tylko jedną z niewielu metod inwersji.

Aby przeczytać więcej na ten temat możesz przeczytać mój blog Tutaj

Co to jest?

Jest to praktyka, w której pozwala się na rzeczywiste zachowanie spoza granicy (klasa w programowaniu obiektowym). Tylko jednostka graniczna zna abstrakcję (np. interfejs, klasa abstrakcyjna, delegat w programowaniu obiektowym).

1. jakie problemy rozwiązuje?

W terminologii programowania IoC próbuje rozwiązać kod monolityczny, czyniąc go modularnym, oddzielając różne jego części i czyniąc go jednostkowym testowalnym.

Kiedy jest to właściwe, a kiedy nie?

Jest to właściwe przez większość czasu, chyba że masz sytuację, w której chcesz po prostu kod monolityczny (np. bardzo prosty program)

Używając IoC nie jesteś nowy w swoich obiektach. Twój kontener IoC będzie to robił i zarządzał ich żywotnością.

Rozwiązuje problem konieczności ręcznej zmiany każdej instancji jednego typu obiektu na inny.

Jest to właściwe, gdy masz funkcjonalność, która może się zmienić w przyszłości lub która może być inna w zależności od środowiska lub konfiguracji używanej w.