Inversion of Control/Dependency Injection & StructureMap cz.1

Inversion of Controle jest techniką programowania w której przepływ kontroli aplikacji jest odwrócony. Inversion of Controle zakłada odwrócenie zależności pomiędzy warstwami aplikacji. Aby to osiągnąć odwrócenie zależności wymaga dwóch technik:
1. Dependency Injection - wstrzykiwanie zależności
2. Service Locator - lokalizator usług.
Dependency Injection jest wzorcem realizującym założenia IOC. Stosujemy go po to aby izolować klasy od konkretnych implementacji poprzez zamienianie tych implementacji na luźne powiązania. Cel ten uzyskiwany jest poprzez stosowanie klas abstrakcyjnych i interfejsów.
Główne zasady DI to:
- moduły wysokiego poziomu nie powinny zależeć od modułów poziomu niskiego. Obydwa powinny zależeć od abstrakcji
- abstrakcja nie powinna zależeć od szczegółów. Natomiast szczegóły powinny zależeć od abstrakcji.
Stosowanie zasad DI powoduje, że zmiany w modułach na niskim poziomie nie powodują konieczności wprowadzenia zmian na poziomach wyższych.
Istnieją trzy możliwości wstrzykiwania zależności:
- konstruktor wstrzykujący - może być niewydajny gdy w klasie mamy bardzo dużo zależności
- pole strzykujące (setter injection)
- metoda wstrzykująca

Zalety stosowanie DI:
- niezależność kodu
Zależności, które zostały zamienione na obiekty interfejsów są niezależne. W każdej chwili do takiej zależności mogą być podstawione alternatywne obiekty. Dodatkowo posiadając metody, konstruktory i pola wstrzykujące nie trzeba zmieniać klas implementujących te interfejsy.

- elastyczność
Zmiana modułów niższego poziomu nie powoduje potrzeby zmian w klasach rzędu wyższego. Jeśli moduły wyższego rzędu implementują klasy niższego rządu w postaci interfejsów to zależności te nie zawierają konkretnego obiektu. Nie musimy do takich zależności podstawiać obiektów o konkretnym typie.

- separacja współpracy
Ten punkt dotyczy tego, iż powinniśmy tak tworzyć oprogramowanie aby klasy niższego rzędu wykonywały określone zadanie np. zapisanie jakiego obiektu. Dzięki w klasach wyższego rzędu tylko wywołujemy określone metody pewnych zależności.

- oprogramowanie tworzone zgodnie z zasadami DI mogą być ponownie wykorzystywane
Klasy stworzone zgodnie z zasadami DI mogę być ponownie wykorzystane z dowolną liczbą nowych implementacji obiektów niższego rzędu bez konieczności zmiany już istniejących.

- Łatwość konserwacji
Dzięki DI uzyskujemy przejrzystość kodu. W klasach wyższego rządu w łatwy sposób możemy odnaleźć zależności i w łatwy i szybki sposób je zweryfikować

Ideą lokalizatora usług jest stworzenie obiektu, który może przetrzymywać wszystkie usługi, które dana aplikacja może potrzebować. Obiekt taki powinien mieć metodę, która zwraca określoną usługę gdy jest ona potrzebna aplikacji. Lokalizator usług jest również techniką wstrzykiwania zależności ale działającą trochę w inny sposób. Ideę Service Locator'a postaram się przybliżyć w następnym artykule.

Kontenery IOC służą do wstrzykiwania poprawnych zależności. Dzięki zastosowaniu kontenerów IOC w klasach wyższego rzędu nie musimy dokładnie określać, które obiekty zostaną zaimplementowane do określonych zależności. Wystarczy, że zadeklarujemy to w kontenerze IOC. To kontener zwraca określoną instancję klasy.
W kontenerze IOC znajduje się wiedza w jaki sposób tworzymy określone obiekty. To kontener wie jaka właściwa impelemntacja zostanie użyta. Nie musimy tego zapisywać w klasach wyższego rzędu.