Co to jest odwrócenie kontroli?

1825

Inwersja kontroli (IoC) może być dość myląca, gdy zostanie po raz pierwszy napotkana.

Co to jest?
Który problem rozwiązuje?
Kiedy należy używać, a kiedy nie?

oop design-patterns inversion-of-control

— Mike Minutillo
źródło

292

Problemem większości tych odpowiedzi jest stosowana terminologia. Co to jest pojemnik? Odwrócenie? Zależność? Wyjaśnij to w sposób laicki bez wielkich słów.

— kirk.burleson

13

Zobacz także na Programmers.SE: Dlaczego Inversion of Control ma taką nazwę?

— Izkata

8

To jest Dependency Injection (DI) - patrz opis Martina Fowlersa

— Ricardo Sanchez

7

To zdjęcie w

— pewnym sensie

To przymiotnik, nie rzeczownik, to nie rzecz, to opis zmiany dokonanej w kodzie, w której kontrola przepływu odbywa się w delegacie, a nie w kontenerze.

— Martin Spamer,

1523

Wzorce Inversion of Control (IoC) i Dependency Injection (DI) polegają na usuwaniu zależności z kodu.

Załóżmy na przykład, że Twoja aplikacja ma edytor tekstu i chcesz sprawdzić pisownię. Twój standardowy kod wyglądałby mniej więcej tak:

public class TextEditor {

    private SpellChecker checker;

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

To, co tutaj zrobiliśmy, tworzy zależność między TextEditori SpellChecker. W scenariuszu IoC zamiast tego zrobilibyśmy coś takiego:

public class TextEditor {

    private IocSpellChecker checker;

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

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

W drugim przykładzie kodu tworzymy abstrakcję, mając SpellCheckerklasę zależności w TextEditorsygnaturze konstruktora (nie inicjując zależności w klasie). Dzięki temu możemy wywołać zależność, a następnie przekazać ją do klasy TextEditor w następujący sposób:

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

Teraz klient tworzący TextEditorklasę ma kontrolę nad tym, której SpellCheckerimplementacji użyć, ponieważ wprowadzamy zależność do TextEditorpodpisu.

— urini
źródło

50

Dobry jasny przykład. Załóżmy jednak, że zamiast wymagać, aby interfejs ISpellChecker był przekazywany do konstruktora obiektu, ujawniliśmy go jako ustawialną właściwość (lub metodę SetSpellChecker). Czy nadal stanowiłoby to IoC?

— devios1,

25

chainguy1337 - tak by to zrobiło. Użycie takich ustawiaczy nazywa się zastrzykiem ustawiającym w przeciwieństwie do wstrzykiwania konstruktora (obie techniki wstrzykiwania zależności). IoC to dość ogólny wzorzec, ale bolą ją iniekcje zależności IoC

— Jack Ukleja

257

Pomimo wielu głosów pozytywnych, ta odpowiedź jest nieprawidłowa. Zobacz martinfowler.com/articles/injection.html#InversionOfControl . W szczególności zwróć uwagę na część „Inwersja kontroli jest zbyt ogólnym terminem, dlatego ludzie uważają go za mylący. W wyniku wielu dyskusji z różnymi zwolennikami IoC zdecydowaliśmy się na nazwę Dependency Injection”.

— Rogério

45

Zgadzam się z @Rogeria. to nie wyjaśnia, dlaczego nazywa się to IoC i jestem zaskoczony liczbą głosów ;-)

— Aravind Yarram,

31

Popieram @Rogerio i @Pangea. Może to być dobry przykład wstrzyknięcia konstruktora, ale nie dobra odpowiedź na pierwotne pytanie. IoC, zgodnie z definicją Fowlera , można zrealizować bez użycia jakiegokolwiek zastrzyku, np. Za pomocą lokalizatora usług lub nawet zwykłego dziedziczenia.

— mtsz

642

Odwrócenie kontroli jest tym, co dostajesz, gdy Twój program wywołuje zwrotne, np. Jak program GUI.

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

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

kontrolując w ten sposób przepływ interakcji użytkownika.

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

Teraz kontrola jest odwrócona ... zamiast komputera akceptującego dane wejściowe użytkownika w ustalonej kolejności, użytkownik kontroluje kolejność wprowadzania danych i zapisywania danych w bazie danych.

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

— Mark Harrison
źródło

161

nie zaznaczaj tego faceta. technicznie ma rację martinfowler.com/bliki/InversionOfControl.html IoC jest bardzo ogólną zasadą . Przepływ kontroli jest „odwrócony” przez wstrzyknięcie zależności, ponieważ skutecznie delegowano zależności do jakiegoś systemu zewnętrznego (np. Kontener IoC)

— Jack Ukleja,

38

Zgodził się z komentarzem Schneidera. 5 głosów negatywnych? Umysł drży, ponieważ jest to jedyna prawdziwa odpowiedź. Zwróć uwagę na otwarcie: „ jak program GUI”. Zastrzyk zależności jest tylko najczęściej spotykaną realizacją IoC.

— Jeff Sternal

40

Rzeczywiście, jest to jedna z niewielu poprawnych odpowiedzi! Ludzie, IoC nie polega zasadniczo na zależnościach. Ani trochę.

— Rogério

13

+1 - To jest dobry opis (z przykładem) następującej wypowiedzi Martina Fowlera: „Wczesne interfejsy użytkownika były kontrolowane przez aplikację. Miałbyś sekwencję poleceń takich jak„ Wprowadź nazwę ”,„ wprowadź adres ”; twój program sterował monitami i odbierał odpowiedzi na każde z nich. W graficznych (lub nawet ekranowych) interfejsach użytkownika interfejs zawierałby tę główną pętlę, a program zamiast tego zapewniał obsługę zdarzeń dla różnych pól na ekranie. program został odwrócony, przeniesiony z dala od ciebie do frameworka. ”

— Ashish Gupta

14

Rozumiem teraz, dlaczego czasami jest żartobliwie nazywany „zasadą Hollywood: nie dzwoń do nas, zadzwonimy do ciebie”