W jaki sposób inwersja kontroli jest powiązana z inwersją zależności

12

W wielu artykułach w Internecie pojęcia Inwersja kontroli i zasada inwersji zależności wydają się być pomieszane i używane jako synonimy (dalsze zamieszanie jest wymuszane przez narzędzia nazywane „kontenerami DI” i „kontenerami IoC”). Artykuł w Wikipedii robi dobrą robotę, próbując wyjaśnić, że IoC to nie to samo, co DI:

inwersja kontroli (IoC) opisuje projekt, w którym niestandardowe części programu komputerowego odbierają przepływ kontroli z ogólnej biblioteki wielokrotnego użytku

Tak więc DIP polega na tym, aby moduły zależały od abstrakcji, a nie od konkretnych implementacji.

IoC polega na przekazaniu kontroli nad przepływem programu do oddzielnego modułu. Jedną z rzeczy, które możesz zrobić w tym module, jest rozwiązanie zależności w czasie wykonywania.

Ta różnica wydaje się sprawiedliwa, ale nigdy nie widziałem, aby ktokolwiek wspominał o innych zastosowaniach zasady IoC innych niż rozwiązywanie zależności. Definicja Wikipedii jest dość szeroka i wydaje się, że możesz zrobić o wiele więcej dzięki modułowi, który ma możliwość wykonywania wywołań w niestandardowym kodzie na podstawie jego konfiguracji i wewnętrznej logiki.

Oto kilka pytań, których nie potrafię do końca zrozumieć:

  • Jaki jest faktyczny związek między IoC a DIP? Czy IoC zawsze służy jako środek implementacji DIP?
  • Dlaczego narzędzia do rozwiązywania zależności nazywane są zarówno kontenerami DI, jak i IoC? Oznacza to, że DI i IoC są tym samym.

Uwaga : To pytanie nie jest duplikatem Jaka jest różnica między DI a IoC , ponieważ ten ostatni pyta o Wstrzyknięcie zależności, a nie Odwrócenie zależności.

design-patterns inversion-of-control dependency-inversion Andre Borges
źródło
Możliwy duplikat Jaka jest różnica między DI a IoC?
komara
@gnat, nie, nie jest, proszę zobaczyć moją edycję
Andre Borges
Zgadzam się, tęskniłem za tym przepraszam
komara
2
IMO, prosta odpowiedź brzmi „są tacy sami”. IoC to inna nazwa inwersji zależności i oba są sposobem na osiągnięcie zastrzyku zależności. Widzę „inwersję zależności” jako bardzo nieprzydatny termin, ponieważ zbyt łatwo można go pomylić z zastrzykiem. Jest więc DI (wtrysk), a IoC jest sposobem na osiągnięcie inwersji zależności / kontroli poprzez wtrysk.
David Arno,

Odpowiedzi:

6

Istnieje świetny artykuł na stronie Martina Fowlera, który zawiera rozdział poświęcony różnicy między DIP, DI i IoC . Istota tego (skopiowana z tej strony) to

DI dotyczy tego, jak jeden obiekt nabywa zależność. Gdy zależność jest zapewniana zewnętrznie, system używa DI. IoC dotyczy tego, kto inicjuje połączenie. Jeśli Twój kod inicjuje wywołanie, nie jest nim IoC, jeśli kontener / system / biblioteka wywołuje z powrotem kod, który podałeś, to jest to IoC.

Z kolei DIP dotyczy poziomu abstrakcji w wiadomościach wysyłanych z Twojego kodu do rzeczy, którą wywołuje. Oczywiście używanie DI lub IoC z DIP jest bardziej ekspresyjne, wydajne i dostosowane do domeny, ale dotyczą one różnych wymiarów lub sił, stanowiących ogólny problem. DI to okablowanie, IoC to kierunek, a DIP to kształt.

JDT
źródło
2
IoC polega na tym, kto inicjuje połączenie - kto go inicjuje? Jeśli piszę, ISomeInterface object = container.Resolve<ISomeInterface>()czy to IoC, czy nie?
Andre Borges,
1
To, co piszesz, jest implementacją we wzorcu lokalizatora usług. To także IoC. Nie IoC to obiekt ISomeInterface = new MyClass (). Tak więc wezwaniem jest „wezwanie do utworzenia instancji” (lub kto nazywa „nowy”).
Sjoerd222888
1
„DIP, z drugiej strony, dotyczy poziomu abstrakcji w wiadomościach wysyłanych z twojego kodu do rzeczy, którą woła”. Dla mnie to brzmi jak nonsens. Gdzie w tym jest odwrócenie? Opisuje abstrakcję zależności, a nie inwersję.
David Arno,
@DavidArno, czy mówisz, że nie możemy ufać stronie Martina Fowlera?
holdenmcgrohen
@holdenmcgrohen, to jego opinie na różne tematy. To, że to Martin Fowler, nie jest faktem. Myli się czasami IMO, np. W odniesieniu do „modelu danych anemii”. Innym razem jego wnikliwość. Przy tej okazji myślę, że on też się myli, ponieważ to nie ma sensu.
David Arno,