26
May

Kilka postów o Dependency Injection

Ten post jest częścią cyklu o Dependency Injection.


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!

Autor

Maciej Aniserowicz

Maciej Aniserowicz
"Procent"
developer / architect

MVP
MCP

Search
Facebook
Twitter
Archiwum
Kategorie
© Copyright 2008-2014 Maciej Aniserowicz. All rights reserved. Running on WordPress.