b'\n_START_ARTICLE_\nWstrzykiwanie zale\xc5\xbcno\xc5\x9bci\n_START_PARAGRAPH_\nWstrzykiwanie zale\xc5\xbcno\xc5\x9bci (ang. Dependency Injection, DI) \xe2\x80\x93 wzorzec projektowy i wzorzec architektury oprogramowania polegaj\xc4\x85cy na usuwaniu bezpo\xc5\x9brednich zale\xc5\xbcno\xc5\x9bci pomi\xc4\x99dzy komponentami na rzecz architektury typu plug-in. Polega na przekazywaniu gotowych, utworzonych instancji obiekt\xc3\xb3w udost\xc4\x99pniaj\xc4\x85cych swoje metody i w\xc5\x82a\xc5\x9bciwo\xc5\x9bci obiektom, kt\xc3\xb3re z nich korzystaj\xc4\x85 (np. jako parametry konstruktora). Stanowi alternatyw\xc4\x99 do podej\xc5\x9bcia, gdzie obiekty tworz\xc4\x85 instancj\xc4\x99 obiekt\xc3\xb3w, z kt\xc3\xb3rych korzystaj\xc4\x85 np. we w\xc5\x82asnym konstruktorze. _NEWLINE_Jest on cz\xc4\x99sto uto\xc5\xbcsamiany z odwr\xc3\xb3ceniem sterowania (ang. Inversion of Control, IoC), jakkolwiek z technicznego punktu widzenia DI jest jedn\xc4\x85 ze szczeg\xc3\xb3lnych (obecnie najpopularniejsz\xc4\x85) realizacji paradygmatu IoC._NEWLINE_DI silnie preferuje zewn\xc4\x99trzne tworzenie po\xc5\x82\xc4\x85cze\xc5\x84 (zale\xc5\xbcno\xc5\x9bci) pomi\xc4\x99dzy komponentami oprogramowania (np. asocjacje w klasach), nad zlecaniem tworzenia zale\xc5\xbcno\xc5\x9bci im samym. Jest to wzorzec, w kt\xc3\xb3rym odpowiedzialno\xc5\x9b\xc4\x87 za tworzenie i \xc5\x82\xc4\x85czenie obiekt\xc3\xb3w jest przeniesiona z obiekt\xc3\xb3w do fabryki (np. kontenera IoC). Na \xc5\xbc\xc4\x85danie kodu fabryka tworzy obiekt, lub udost\xc4\x99pnia obiekt z puli obiekt\xc3\xb3w, ustawiaj\xc4\x85c mu powi\xc4\x85zania z innymi obiektami (np. wstrzykiwanie konstruktorem \xe2\x80\x93- Constructor Injection, wstrzykiwanie mutatorami \xe2\x80\x93 Setter Injection, u\xc5\xbcycie interfejsu Interface Injection lub w mieszany spos\xc3\xb3b). DI jest wi\xc4\x99c realizacj\xc4\x85 \xe2\x80\x9eodwr\xc3\xb3cenia sterowania\xe2\x80\x9d w sensie tworzenia i wi\xc4\x85zania obiekt\xc3\xb3w._NEWLINE_W rozbudowanych implementacjach fabryka mo\xc5\xbce wykonywa\xc4\x87 czynno\xc5\x9bci dodatkowe, np. Spring Framework pozwala na u\xc5\xbcywanie aspekt\xc3\xb3w, mo\xc5\xbcna wi\xc4\x99c do obiektu doda\xc4\x87 automatycznie obs\xc5\x82ug\xc4\x99 transakcji, logowania, itp._NEWLINE_DI jest sposobem osi\xc4\x85gni\xc4\x99cia lu\xc5\xbanych powi\xc4\x85za\xc5\x84 (ang. loose coupling). _NEWLINE_U\xc5\xbcycie tej techniki pozwala tworzy\xc4\x87 \xc5\x82atwo testowalne obiekty. Sprawdza si\xc4\x99 szczeg\xc3\xb3lnie w powi\xc4\x85zaniu z programowaniem sterowanym testami (ang. test-driven development). Polega ono w skr\xc3\xb3cie na nast\xc4\x99puj\xc4\x85cym tworzeniu oprogramowania: opracowujemy interfejsy (diagram klas), opracowujemy testy jednostkowe, kt\xc3\xb3re testuj\xc4\x85 funkcjonalno\xc5\x9b\xc4\x87 interfejsu (w jaki spos\xc3\xb3b przetestowa\xc4\x87, czy dzia\xc5\x82anie jest poprawne), a dopiero p\xc3\xb3\xc5\xbaniej piszemy implementacj\xc4\x99. Unikanie zale\xc5\xbcno\xc5\x9bci od konkretnych implementacji wsp\xc3\xb3\xc5\x82pracuj\xc4\x85cych klas, a bazowanie tylko na interfejsach umo\xc5\xbcliwia tworzenie kontrolowanych test\xc3\xb3w - jeste\xc5\x9bmy w stanie skupi\xc4\x87 si\xc4\x99 wy\xc5\x82\xc4\x85cznie na funkcjonalno\xc5\x9bci wybranej klasy; zw\xc5\x82aszcza, gdy wykorzystamy obiekty-za\xc5\x9blepki (ang. mock-objects, proste pseudoimplementacje, u\xc5\xbcywane w celu testowania). DI pozwala wstrzykn\xc4\x85\xc4\x87 do obiekt\xc3\xb3w testowanych zale\xc5\xbcno\xc5\x9bci od obiekt\xc3\xb3w-za\xc5\x9blepek. W \xc5\x9brodowisku produkcyjnym do obiekt\xc3\xb3w tych wstrzykiwane s\xc4\x85 zale\xc5\xbcno\xc5\x9bci od prawdziwych obiekt\xc3\xb3w.'