Kilka postów o Dependency Injection

13

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!

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor jedynego polskiego podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook.

13 Comments

  1. Pingback: dotnetomaniak.pl

  2. Tymoteusz zza miedzy on

    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.

  3. 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.

  4. 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).

  5. Tymoteusz,
    Mam nadzieję w takim razie że ten cykl rozjaśni ci całą sprawę, jest na poziomie dość początkującym.

  6. 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.

  7. 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.

  8. 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 :).