Jak można było dowiedzieć się z moich ostatnich postów społecznościowo-konferencyjnych (jeden, drugi, trzeci), miałem ostatnio prezentacje na temat Dependency Injection. Dość dziwne jest to o tyle, że na ten temat nie blogowałem właściwie od czterech lat. Pora zaległości nadrobić:).
Pojawiły się za to treści gdzieś indziej. Po jednym z moich występów Basia podjęła temat. Po jej poście Paskol też coś naskrobał. A i w polskiej-anglojęzycznej blogosferze znalazło się miejsce na DI, chociaż nie wiem czy było to zależne od poprzednich wpisów czy też nie.
W kilku następnych postach planuję przedstawić swoją prezentację, ale w formie pisanej. Przejedziemy się po pokazywanym przeze mnie kodzie, obserwując istniejącą pseudo-aplikację przed, w trakcie i po procesie “refaktoryzacji” z brzydkiego fe-kodu do nieidealnej, ale lepszej postaci, osiągniętej dzięki DI.
Kod, który będę pokazywał, jest dostępny na GitHubie: https://github.com/maniserowicz/di-talk. Zachęcam do sklonowania tego repo. Niektóre kawałki kodu będę przeklejał do postów, ale najwięcej będzie można wyczytać poruszając się po tak zwanym żywym organizmie.
Małe wtrącenie: w czerwcu mam zaplanowane kolejne wystąpienie z tym tematem. Jeśli więc, czytelniku najdroższy umiłowany, wybierasz się na spotkanie ze mną w Olsztynie, to odpuść póki co te posty gdyż spoilerem są niesamowitym i będzie ci nudno :). Początkowo planowałem publikację tego cyklu po zakończeniu “DI-tournee”, ale rency sami się zaczęli rwać do pisania, więc i zwlekać nie ma co… bo ochota odejdzie.
A póki co… po co w ogóle DI?
Dependency Inversion Principle jest ostatnią w pakiecie dobrych praktyk SOLID. Mamy więc SOLIDependency Inversion. Jest ona o tyle nieodzowna, że de facto umożliwia, a nawet sugeruje, zastosowanie wszystkich pozostałych zasad. Wykorzystując dobra niesione przez DI uzyskamy kod, który będzie czytelniejszy niż do tej pory. A skoro jest czytelniejszy, to będzie łatwiej go zrozumieć. Zatem: łatwiej utrzymywać.
Niejako bonusowo wzrośnie też testowalność pisanego przez nas rozwiązania, co zobaczymy na przykładach. Dodatkowo otrzymamy możliwość bezbolesnej, w teorii, podmiany implementacji niektórych komponentów, choć to akurat jest kwestia dosyć dyskusyjna…
Ale, dość gadania, show me the code! Już za minutkę, już za momencik… Do następnego!
Kilka postów o Dependency Injection | Maciej Aniserowicz o programowaniu…
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl…
Kurcze, mimo usilnych prób nie jestem w stanie pojąć koncepcji DI. Czytam o tym, patrze na kody i nic. Nie widzę jak tego używać w praktyce.
PoorMansContainer :D
DI może i sprawia ze kod jest czytelniejszy i używam kiedy tylko mogę (a czasem nawet i kiedy nie mogę) ale jak każda technologia niesie swoje własne problemy które zaciemniają problem. W tamtym tygodniu walczyłem z dziwnym błędem który nie wydawał mi się nawet w ogóle możliwy. A wyszło na to że namieszałem w konfiguracji cyklu życia obiektów DI.
Ale w twoim przypadku nie sama idea DI nie stworzyła twojego problemu. Ani go nie zaciemniła. Pokiełbasiłeś konfigurację, a powiesz, że to to DI jest złe.
A czy ja mówię że DI jest złe. Ja dla mnie to najlepsza rzecz od czasu wynalezienie mleka w proszku. Ale jak zawsze użycie czegoś rozwiązuje jakiś zestaw problemów a rodzi kompletnie inny (co nie znaczy że z automatu gorszy).
Tymoteusz,
Mam nadzieję w takim razie że ten cykl rozjaśni ci całą sprawę, jest na poziomie dość początkującym.
Jacek, Paweł,
Jak zawsze – korzystając z czegoś (szczególnie tak skomplikowanego jak konfiguracja kontenera IoC…) trzeba się najpierw tego nauczyć. A w przypadku kontenerów – najlepiej jeszcze pokryć testami upewniając się że wszystkie niestandardowe (tzn nie-transient) obiekty są faktycznie tworzone tak jak tego chcemy.
Procent,
Co ‘standardowego’ cyklu życia obietku polecam się upewnic mimo wszsytko bo np. dla Castle Windsor defaultem jest singleton – o czym przekonanie się kosztowało mnie kilka wtf.
Niestety tak jest. Ale jest napisane, i przed użyciem trzeba było (w moim przypadku) swoje odczytać:
http://docs.castleproject.org/Default.aspx?Page=LifeStyles&NS=Windsor&AspxAutoDetectCookieSupport=1
Dodam tylko, że ja jeszcze skrobania nie skończyłem ;), a wręcz kontynuuje (http://paskol.robi.to/?p=1945).
Adam,
Z Castle Windsor co prawda nigdy nie korzystałem, ale bym w życiu nie założył że domyślnie jest singleton! Faktycznie, dzięki. Nie znalazłem uzasadnienia dla tej decyzji, bardziej logiczne wydaje mi się podejście Autofac, czyli transient. Najmniej logiczna ze wszystkich z kolei jest logika w TinyIoC, gdzie domyślny cykl życia zależy od tego czy rejestrujemy klasę jako klasę czy jako interfejs :).
PaSkol,
Cieszy mnie ten fakt niezmiernie i zamierzam czytać wiernie :)