W sobotę odbyła się łódzka konferencja GET.NET (o czym jeszcze napiszę), w trakcie której tuż przed moją, odbyła się prezentacja Procenta o Dependency Injection. Samo wystąpienie było świetne, a moją ciekawość podsyciła dodatkowo obietnica (powtórzona dwukrotnie) wyjaśnienia całego zamieszania wokół pojęć DI (Dependency Injecton i Inversion) oraz IoC. Jakie było moje rozczarowanie, gdy upragniony moment nadszedł, a Maciek skwitował wszystko zdaniem, że definicje nie są ważne.

Oj wkurzyłam się… Pomyślałam – naprawdę? Czy to, że ludzie mylą te pojęcia oznacza, że powinniśmy to olać i pozwolić, by żółć sączyła się z rany? Oczywiście zgadzam się z ogólnym stwierdzeniem, że w sumie nie ważna jest nomenklatura, byle dobre praktyki stosować, ale… czy na pewno tak jest do końca? Czy SRP pod inna nazwą równie by pachniała? Czy od teraz powinniśmy się komunikować opisując co dana zasada czy wzorzec robi, zamiast operować ich nazwami? Jakoś tego nie widzę, zajmowałoby to stanowczo za dużo czasu.

No to jak to jest z tym IoC i DI? Ano bardzo prosto, aż szkoda, że tyle przekłamań w internetach. Zacznijmy od ogółu.

Inversion of Control

IoC jest zasadą, która przeciwstawia się tradycyjnemu proceduralnemu podejściu do programowania. Polega na odwróceniu kontroli (tak, wiem, że rozumiecie ), w taki sposób, by miał ją zewnętrzny kod zamiast głównego flowu.

A oto obrazek przedstawiający ideę, zapożyczony z ok kolegi z fb, gdyż stwierdził (a ja się zgodziłam), że go tu brakuje.

W tradycyjnym podejściu nasz program wykonuje kroki, wywołując metody bibliotek, do których posiada on referencje. W podejściu IoC natomiast, to zewnętrzny software wywołuje nasz kod by wykonać pewne akcje. Relacje wtedy układają się zupełnie na odwrót. Dlatego zasada ta jest często żartobliwie nazywana regułą Hollywood: Don’t call us, we’ll call you.

Jest to więc bardzo szerokie pojęcie, dużo szersze niż wstrzykiwanie zależności, czy Service Locator. Przykładami z innej bajki są eventy, callbacki, czy zwykłe programowanie bazujące na interfejsach (np. wzorzec strategii).

Dependency Injection

Czyli wiemy już, że DI jest po prostu jedną z implementacji IoC. Wzorcem projektowym polegającym na tym, że przekazujemy (injection) zależność (dependency) do obiektu. Zależność staje się częścią stanu klienta (np. polem klasy lub jego property). Kluczową sprawą jest fakt jej przekazania, by nie pozwalać na tworzenie lub pozyskiwanie jej po stronie używającego obiektu.

Dependency Inversion

A jak się ma do tego Dependency Inversion? Jest to jedna z zasad SOLID faworyzująca taką budowę modułów, by odwrócić zależności i wprowadzić jak najbardziej luźne powiązania między nimi. DI oraz Service Locator się do niej stosują. A brzmi ona następująco:

• Moduły wyższego poziomu nie powinny polegać na modułach niższego poziomu, lecz na abstrakcjach
• Abstrakcje nie powinny polegać na konkretnych implementacjach, to konkretne implementacje powinny polegać na abstrakcjach

(Błędnie stosowana często prowadzi do tego, że po prostu wrzucamy na każdym poziomie interfejs, który jest implementowany przez dokładnie jeden moduł, ale to temat na zupełnie inny post.)

Mylić więc Dependency Injection i Dependency Inversion to całkiem normalna sprawa. Natomiast wrzucanie tego do jednego wora z IoC, to już lekkie nadużycie, bo wór ten jest o wiele obszerniejszy.