Jak wstrzykiwanie zależności zwiększa testowalność i modularność

Co oznacza wstrzykiwanie zależności (bez żargonu)

Dependency Injection (DI) to prosta idea: zamiast kod tworzył rzeczy, których potrzebuje, dostajesz je z zewnątrz.

Te „rzeczy” to jego zależności — na przykład połączenie z bazą, serwis płatności, zegar, logger czy wysyłacz e-maili. Jeśli twój kod sam buduje te zależności, utajenie określa jak one działają.

Analogia z życia codziennego

Pomyśl o ekspresie do kawy w biurze. Potrzebuje wody, ziaren i prądu.

• Jeśli maszyna jest zaprojektowana tak, że działa tylko z jednym, opatentowanym wkładem wodnym, który sama kupuje, jesteś skazany na jednego dostawcę.
• Jeśli akceptuje dowolne standardowe źródło wody, ktoś inny może wybrać kran, filtrowaną lub butelkowaną bez zmiany maszyny.

DI to to drugie podejście: „ekspres” (twoja klasa/funkcja) skupia się na robieniu kawy (swoim zadaniu), a „dostawy” (zależności) są zapewniane przez tego, kto go uruchamia.

Czym DI nie jest

DI nie wymaga konkretnego frameworka i nie jest tym samym co kontener DI. Możesz robić DI ręcznie, przekazując zależności jako parametry (lub przez konstruktor) i to wystarczy.

DI to też nie „mockowanie”. Mockowanie to jedna z technik używanych dzięki DI w testach, ale samo DI to decyzja projektowa o tym, gdzie tworzy się zależności.

Dlaczego testowalność i modularność poprawiają się równocześnie

Gdy zależności dostarczane są z zewnątrz, kod staje się łatwiejszy do uruchomienia w różnych kontekstach: produkcja, testy jednostkowe, demonstracje czy przyszłe funkcje.

Ta sama elastyczność upraszcza moduły: części mogą być wymieniane bez przekształcania całego systemu. W efekcie testy są szybsze i czytelniejsze (bo można podmienić proste duble), a baza kodu łatwiejsza do zmiany (bo części są mniej splątane).

Główny problem: silne powiązania utrudniają zmiany

Silne powiązanie występuje, gdy jedna część kodu bezpośrednio decyduje, z czego musi korzystać inna część. Najczęstsza forma to wywoływanie new wewnątrz logiki biznesowej.

Jak bezpośrednia instancjacja tworzy ukryte powiązania

Wyobraź sobie funkcję checkout, która wewnątrz robi new StripeClient() i new SmtpEmailSender(). Na początku wydaje się wygodne — wszystko, czego potrzebujesz, jest pod ręką. Ale blokuje to workflow do tych konkretnych implementacji, szczegółów konfiguracji, a nawet reguł tworzenia (klucze API, timeouty, zachowanie sieciowe).

To powiązanie jest „ukryte”, bo nie widać go w sygnaturze metody. Funkcja wygląda jak przetwarzająca zamówienie, a w rzeczywistości zależy od bramek płatności, dostawców e-maili i być może połączenia z bazą.

Dlaczego trudne do podmiany zależności spowalniają zmiany

Gdy zależności są zakodowane na stałe, nawet drobne zmiany powodują fale:

• Zmiana providera (Stripe → Adyen) oznacza edycję logiki biznesowej zamiast zamiany komponentu.
• Dodanie cache, retry lub logowania zmusza do przekazywania tych aspektów przez wiele miejsc wywołań.
• Aktualizacja biblioteki może wymagać szerokiego refaktoru, bo tworzenie jest rozsiane.

Silne powiązania ujawniają się w wolnych lub niestabilnych testach

Zakodowane zależności sprawiają, że testy jednostkowe wykonują rzeczywiste operacje: wywołania sieci, I/O plików, zegary, losowe ID czy współdzielone zasoby. Testy stają się wolne, bo nie są izolowane, oraz kruche, bo wyniki zależą od czasu, usług zewnętrznych lub kolejności wykonania.

Sygnały bólu, na które warto zwrócić uwagę

Jeśli widzisz te wzory, prawdopodobnie już tracisz czas przez silne powiązania:

• Globalny stan używany jako ukryta zależność
• Singletons trudne do zresetowania między testami
• new rozsiane „wszędzie” w kluczowej logice
• Kod, którego nie da się przetestować bez bazy, serwera WWW lub prawdziwego klucza API

Dependency Injection rozwiązuje to, robiąc zależności jawne i wymienne — bez przepisywania reguł biznesowych za każdym razem, gdy świat się zmienia.

Inwersja kontroli: oddzielanie „co” od „jak”

Inversion of Control (IoC) to prosty przesunięcie odpowiedzialności: klasa powinna skupiać się na tym, co musi robić, a nie jak zdobyć rzeczy, których potrzebuje.

Gdy klasa tworzy swoje zależności (np. new EmailService() lub otwiera połączenie z bazą bezpośrednio), bierze na siebie dwie role: logikę biznesową i konfigurację. To sprawia, że klasa jest trudniejsza do zmiany, ponownego użycia i testowania.

Poleganie na abstrakcjach, nie na klasach konkretnych

W IoC twój kod zależy od abstrakcji — jak interfejsy lub małe typy „kontraktowe” — zamiast od konkretnych implementacji.

Na przykład CheckoutService nie musi wiedzieć, czy płatności są przetwarzane przez Stripe, PayPal czy fałszywy procesor testowy. Potrzebuje jedynie „czegoś, co potrafi obciążyć kartę”. Jeśli CheckoutService przyjmuje IPaymentProcessor, może współpracować z każdą implementacją zgodną z tym kontraktem.

To utrzymuje twoją logikę w ryzach nawet, gdy pod spodem zmieniają się narzędzia.

Przeniesienie tworzenia na zewnątrz klasy

Praktyczna część IoC to wyprowadzenie tworzenia zależności poza klasę i przekazanie ich (często przez konstruktor). Tu wchodzi DI: to popularny sposób osiągnięcia IoC.

Zamiast:

• klasa wybiera i buduje współpracowników

Masz:

• klasa otrzymuje współpracowników z zewnątrz

Efekt to elastyczność: zamiana zachowania staje się decyzją konfiguracyjną, a nie przepisywaniem kodu.

„Composition root”: miejsce, gdzie następuje okablowanie

Jeśli klasy nie tworzą swoich zależności, ktoś inny musi to zrobić. Tym „kimś” jest composition root: miejsce, gdzie aplikacja jest składana — zwykle kod startowy.

Composition root to miejsce, w którym decydujesz: „W produkcji użyj RealPaymentProcessor; w testach użyj FakePaymentProcessor.” Trzymanie okablowania w jednym miejscu zmniejsza niespodzianki i pozwala reszcie kodu koncentrować się na zachowaniu.

Dlaczego to ma znaczenie dla testów i refaktorów

IoC upraszcza testy jednostkowe, bo można dostarczyć małe, szybkie duble testowe zamiast wywoływać prawdziwe sieci czy bazy.

Ułatwia też refaktory: gdy odpowiedzialności są rozdzielone, zmiana implementacji rzadko wymusza zmianę klas ją używających — pod warunkiem, że abstrakcja pozostanie taka sama.

Popularne style DI i kiedy ich używać

Dependency Injection (DI) to nie pojedyncza technika — to zbiór sposobów „karmienia” klasy rzeczami, których potrzebuje (logger, klient DB, bramka płatności). Styl, który wybierzesz, wpływa na czytelność, testowalność i ryzyko nadużyć.

Wstrzykiwanie przez konstruktor (domyślne)

W constructor injection zależności są wymagane do zbudowania obiektu. To duża zaleta: nie można ich przypadkowo pominąć.

Pasuje, gdy zależność:

• jest zawsze potrzebna by obiekt działał
• jest współdzielona przez wiele metod
• ważne jest wczesne sprawdzenie (np. null/undefined nie powinno być dozwolone)

Constructor injection daje zwykle najbardziej przejrzysty kod i najprostsze testy jednostkowe, bo w teście możesz przekazać fałszywy lub mock już przy tworzeniu.

Wstrzykiwanie przez parametr/metodę (na jednorazowe użycie)

Czasem zależność jest potrzebna tylko do jednej operacji — np. tymczasowy formatter, specjalna strategia lub wartość w zakresie żądania. W takich przypadkach przekaż ją jako parametr metody. Zmniejsza to rozmiar obiektu i zapobiega „promocji” jednorazowej potrzeby do trwałego pola.

Wstrzykiwanie przez właściwość/setter (używaj ostrożnie)

Setter injection bywa wygodne, gdy nie da się dostarczyć zależności w konstruktorze (pewne frameworki lub legacy). Kosztem jest to, że może ukryć wymagania: klasa wygląda jak nadająca się do użycia, nawet gdy nie jest w pełni skonfigurowana.

Często prowadzi to do niespodzianek w czasie wykonywania („dlaczego to jest undefined?”) i sprawia testy bardziej kruche, bo łatwo pominąć konfigurację.

Proste reguły praktyczne

• Jeśli klasa nie może działać bez tej zależności: constructor injection.
• Jeśli to tylko potrzeba jednego wywołania: method/parameter injection.
• Jeśli musisz wspierać późne okablowanie: setter injection, ale dodaj zabezpieczenia (dokumentacja, walidacja, fail-fast).

Jak DI poprawia testy jednostkowe (szybkość, izolacja, czytelność)

Testy jednostkowe są najbardziej użyteczne, gdy są szybkie, powtarzalne i skupione na jednym zachowaniu. Gdy test „jednostkowy” zależy od prawdziwej bazy, sieci, systemu plików czy czasu, zaczyna się zwalniać i stawać niestabilny. Porażki przestają być informacyjne: czy kod się zepsuł, czy środowisko się potknęło?

Dependency Injection (DI) rozwiązuje to, pozwalając kodowi przyjmować rzeczy, których potrzebuje (dostęp do DB, klient HTTP, dostawca czasu) z zewnątrz. W testach możesz je zamienić na lekkie substytuty.

Szybkość: trzymaj testy w pamięci

Prawdziwa baza lub wywołanie API dodaje czas i opóźnienia. Dzięki DI możesz wstrzyknąć repozytorium w pamięci lub fałszywy klient, który zwraca przygotowane odpowiedzi natychmiast. To oznacza:

• więcej testów w tym samym czasie
• większa skłonność do uruchamiania ich często
• szybsze pipelines CI

Izolacja: testuj jedną rzecz na raz

Bez DI kod często „new()uje” swoje zależności, zmuszając testy do ćwiczenia całej stosu. Dzięki DI możesz wstrzyknąć:

• mocks do weryfikacji interakcji (np. „wysłano jeden e-mail”)
• stubs zwracające określone wartości (np. „użytkownik istnieje”)
• fakes z prostym działającym zachowaniem (np. repozytorium w pamięci)

Bez hacków i globalnych przełączników — po prostu przekaż inną implementację.

Czytelność: prosty Arrange–Act–Assert

DI sprawia, że konfiguracja jest jawna. Zamiast szukać konfiguracji, łańcuchów połączeń czy zmiennych środowiskowych testu, czytasz test i od razu widzisz, co jest realne, a co podmienione.

Typowy test przyjazny DI wygląda tak:

1. Arrange: stwórz serwis z fałszywym repozytorium i stubowanym zegarem
2. Act: wywołaj metodę
3. Assert: sprawdź wartość zwracaną i/lub weryfikuj interakcje mocka

Ta bezpośredniość redukuje szum i sprawia, że błędy są łatwiejsze do zdiagnozowania.

Test seams: świadome miejsce do podmiany zachowania

Seam testowy to celowe „otwarcie” w kodzie, gdzie możesz podmienić jedno zachowanie na inne. W produkcji podłączasz prawdziwą rzecz. W testach podłączasz bezpieczny, szybki substytut. DI jest jednym z najprostszych sposobów tworzenia takich seamów bez sztuczek.

Gdzie zwykle umieszcza się seams

Seamy są przydatne wokół części systemu trudnych do kontrolowania w teście:

• Czas (aktualna data/godzina zmienia się ciągle)
• System plików (wolne, prawa dostępu, sprzątanie)
• E-mail/SMS (efekty uboczne, zewnętrzne usługi)
• Bramki płatności (prawdziwe pieniądze, błędy sieciowe)

Jeśli logika biznesowa wywołuje te rzeczy bezpośrednio, testy stają się kruche: zawodzą z powodów niezwiązanych z logiką (awarie sieci, różnice stref czasowych, brak plików) i są trudniejsze do szybkiego uruchamiania.

Interfejsy (lub kontrakty) zamieniają seamy w prosty wybór

Seam często ma postać interfejsu — albo w językach dynamicznych prostego kontraktu, np. „obiekt musi mieć metodę now()”. Klucz: zależ od tego, czego potrzebujesz, nie skąd to pochodzi.

Na przykład zamiast odczytywać zegar systemowy wewnątrz serwisu zamówień, możesz zależeć od Clock:

• Produkcja: SystemClock.now()
• Test: FakeClock.now() zwraca stały czas

Ten sam wzorzec działa dla odczytu plików (FileStore), wysyłania e-maili (Mailer) czy obciążania kart (PaymentGateway). Logika biznesowa zostaje niezmienna; zmienia się tylko wtyczka.

Dlaczego seams prowadzą do lepszych testów

Gdy możesz świadomie podmienić zachowanie:

• Testy stają się mniej kruche: brak zależności od rzeczywistego czasu, sieci czy stanu maszyny.
• Łatwiej pokryć przypadki brzegowe: zasymulujesz „płatność odrzucona”, „timeout e-maila” czy „koniec miesiąca” bez skomplikowanej konfiguracji.
• Błędy są jaśniejsze: jeśli test pada, zwykle znaczy to, że reguła biznesowa jest błędna, a nie że środowisko zawiodło.

Dobrze umieszczone seams redukują potrzebę szerokiego mockowania — dostajesz kilka czystych punktów zamiany, które utrzymują testy szybkie, skupione i przewidywalne.

Jak DI wspiera bardziej modułowy kod

Modularność oznacza, że oprogramowanie jest zbudowane z niezależnych części (modułów) o jasnych granicach: każdy moduł ma skupioną odpowiedzialność i dobrze zdefiniowany sposób interakcji z resztą systemu.

DI wspiera to, czyniąc te granice jawne. Zamiast modułu, który sięga po to, by stworzyć lub znaleźć wszystko, czego potrzebuje, otrzymuje zależności z zewnątrz. Ta mała zmiana zmniejsza wiedzę jednego modułu o drugim.

Niższe powiązanie przez projekt

Gdy kod konstruuje zależności wewnętrznie (np. new-ing klienta bazy w serwisie), wywołujący i zależność są mocno związane. DI zachęca do polegania na interfejsie (lub prostym kontrakcie), nie na implementacji.

To oznacza, że moduł zazwyczaj musi wiedzieć:

• czego potrzebuje (np. PaymentGateway.charge()),
• nie jak to jest zaimplementowane (Stripe vs PayPal vs sandbox)

W efekcie moduły rzadziej zmieniają się razem, bo szczegóły wewnętrzne przestają przepływać przez granice.

Podmieniaj części bez przepisywania wywołujących

Modularny kod pozwala zamienić komponent bez przepisywania konsumentów. DI to umożliwia praktycznie:

• zamień prawdziwy wysyłacz e-mail na wysyłkę do kolejki
• przejdź z repozytorium plikowego na bazę danych
• dodaj dekorator cache wokół istniejącej usługi

We wszystkich przypadkach wywołujący używają tego samego kontraktu. „Okablowanie” zmienia się w jednym miejscu (composition root), zamiast rozproszonych edycji.

Łatwiejsza równoległa praca zespołów

Jasne granice zależności ułatwiają pracę równoległą. Jeden zespół może budować nową implementację za zgadzającym się interfejsem, podczas gdy inny rozwija funkcje zależne od tego interfejsu.

DI wspiera też stopniowy refaktor: możesz wyodrębnić moduł, wstrzyknąć go i stopniowo podmieniać — bez wielkiej migracji.

Prosty przykład przed i po

Zobaczenie DI w kodzie szybciej rozjaśnia niż definicje. Oto mały „przed i po” dla funkcji powiadomień.

Przed: klasa tworzy swoją zależność

Gdy klasa wywołuje new wewnątrz, decyduje którą implementację użyć i jak ją zbudować.

class EmailService {
  send(to, message) {
    // talks to real SMTP provider
  }
}

class WelcomeNotifier {
  notify(user) {
    const email = new EmailService();
    email.send(user.email, "Welcome!");
  }
}

Ból przy testowaniu: test jednostkowy ryzykuje wywołanie prawdziwego zachowania e-mail (albo wymaga niezręcznego globalnego podmieniania).

test("sends welcome email", () => {
  const notifier = new WelcomeNotifier();
  notifier.notify({ email: "[email protected]" });
  // Hard to assert without patching EmailService globally
});

Po: wstrzykuj zależność

Teraz WelcomeNotifier akceptuje dowolny obiekt, który spełnia wymagane zachowanie.

class WelcomeNotifier {
  constructor(emailService) {
    this.emailService = emailService;
  }

  notify(user) {
    this.emailService.send(user.email, "Welcome!");
  }
}

Test staje się mały, szybki i jawny.

test("sends welcome email", () => {
  const fakeEmail = { send: vi.fn() };
  const notifier = new WelcomeNotifier(fakeEmail);

  notifier.notify({ email: "[email protected]" });

  expect(fakeEmail.send).toHaveBeenCalledWith("[email protected]", "Welcome!");
});

Dodanie nowej implementacji jest prostsze

Chcesz SMS zamiast e-mail? Nie dotykasz WelcomeNotifier. Przekazujesz inną implementację:

const smsService = { send: (to, msg) => {/* SMS provider */} };
const notifier = new WelcomeNotifier(smsService);

Praktyczny zysk: testy przestają walczyć z detalami tworzenia, a nowe zachowanie dodaje się przez zamianę zależności zamiast przepisywania istniejącego kodu.

Ręczne DI vs kontenery DI: wybór odpowiedniego poziomu

DI może być tak proste, jak „przekazanie tego, czego potrzebujesz, tam gdzie tego potrzebujesz.” To jest ręczne DI. Kontener DI to narzędzie automatyzujące okablowanie. Oba mogą być dobrym wyborem — trick to dobrać poziom automatyzacji do aplikacji.

Ręczne okablowanie: jawne i łatwe do ogarnięcia

W ręcznym DI tworzysz obiekty samodzielnie i przekazujesz zależności przez konstruktory (lub parametry). To proste:

• Widzisz dokładnie, co jest tworzone i gdzie.
• Nie ma ukrytej magii, gdy coś się psuje.
• Dobre dla małych aplikacji, skryptów, usług z kilkoma komponentami lub wczesnych refaktorów.

Ręczne okablowanie też wymusza dobre praktyki projektowe. Jeśli obiekt potrzebuje siedmiu zależności, od razu poczujesz ból — często znak do podziału odpowiedzialności.

Kontenery DI: mniej boilerplate, lepsze zarządzanie cyklem życia

Gdy liczba komponentów rośnie, ręczne okablowanie może stać się powtarzalnym „rurociągiem”. Kontener DI pomaga:

• budować graf obiektów automatycznie
• zarządzać żywotnością (singleton vs per-request vs transient)
• centralizować rejestracje (np. podmiana serwisów na duble w środowiskach testowych)

Kontenery sprawdzają się w aplikacjach z jasnymi granicami i cyklami życia — aplikacje webowe, długotrwające serwisy lub systemy, gdzie wiele funkcji zależy od wspólnej infrastruktury.

Nie pozwól, żeby kontener ukrył problemy projektowe

Kontener może sprawić, że silnie powiązana architektura poczuje się uporządkowana, bo okablowanie znika. Ale problemy pozostają:

• zbyt wiele zależności w klasie
• niejasna własność (kto tworzy/niszczy zasoby?)
• wzorce „service locator”, które czynią zależności niewidocznymi i utrudniają testy

Jeśli dodanie kontenera sprawia, że kod staje się mniej czytelny, lub deweloperzy przestają wiedzieć, co zależy od czego, to oznaka przedawkowania.

Zrównoważone podejście skalujące się

Zacznij od ręcznego DI, by zachować jasność przy kształtowaniu modułów. Dodaj kontener, gdy okablowanie stanie się powtarzalne lub zarządzanie cyklem życia stanie się problemem.

Praktyczna zasada: używaj ręcznego DI wewnątrz rdzenia/biznesu, a (opcjonalnie) kontenera na granicy aplikacji (composition root) do złożenia wszystkiego. To utrzymuje projekt czytelny, redukując jednocześnie boilerplate w miarę wzrostu projektu.

Typowe pułapki (i jak ich unikać)

Dependency injection może ułatwić testowanie i zmiany — pod warunkiem dyscypliny. Oto najczęstsze sposoby, w jakie DI zawodzi, i praktyki, które pomagają.

Over-injection (problem „konstruktor z 12 parametrami”)

Jeśli klasa potrzebuje długiej listy zależności, często robi za dużo. To nie błąd DI — to DI ujawniające zapach projektowy.

Praktyczna reguła: jeśli nie potrafisz opisać zadania klasy w jednym zdaniu lub konstruktor rośnie, rozważ podział klasy, wyodrębnienie mniejszego współpracownika lub zgrupowanie powiązanych operacji za jednym interfejsem (uważnie — nie twórz kolejnych „bogów-serwisów”).

Service Locator: DI ukrywające prawdziwe zależności

Service Locator wygląda jak wywoływanie container.get(Foo) wewnątrz kodu biznesowego. Wygodne, ale ukrywa zależności: nie da się rozczytać, czego klasa potrzebuje, patrząc na konstruktor.

Testowanie robi się trudniejsze, bo trzeba ustawiać stan globalny (locator) zamiast dostarczać lokalny zestaw dubli. Lepiej przekazywać zależności jawnie (constructor injection jest najprostsze).

Ukryte błędy w czasie wykonywania: brak rejestracji i zależności cyklicznych

Kontenery DI mogą zawieść przy runtime, gdy:

• zależność nie została zarejestrowana
• rejestracja wybiera złą implementację dla środowiska
• dwa serwisy zależą od siebie nawzajem, tworząc cykl

To frustrujące, bo pojawia się dopiero, gdy okablowanie się wykona.

Praktyczne zabezpieczenia

Trzymaj konstruktory małe i skupione. Jeśli lista zależności rośnie, potraktuj to jako sygnał do refaktoru.

Dodaj testy integracyjne dla okablowania. Nawet lekki test kompozycji, który buduje container aplikacji (lub ręczne okablowanie), może złapać brakujące rejestracje i cykle wcześniej — zanim trafi do produkcji.

Wreszcie, trzymaj tworzenie obiektów w jednym miejscu (zwykle start/ composition root) i trzymaj wywołania kontenera z dala od logiki biznesowej. Ta separacja zachowuje główną korzyść DI: jasność, co od czego zależy.

Praktyczne kroki, by wprowadzić DI w istniejącym kodzie

DI najłatwiej wprowadzać jako serię małych, niskoryzykownych refaktorów. Zacznij tam, gdzie testy są wolne lub kruche, i tam, gdzie zmiany często rozlewają się na niepowiązany kod.

Szybka lista kontrolna: gdzie DI się najbardziej opłaca

Szukaj zależności, które utrudniają testowanie lub rozumienie kodu:

• I/O: dostęp do plików, zapytań do bazy, żądań sieciowych
• Czas: "teraz", strefy czasowe, schedulery
• Losowość: UUIDy, losowe liczby, tasowanie
• Zewnętrzne API/SDK: dostawcy płatności, serwisy e-mail, analityka, feature flags

Jeśli funkcja nie może działać bez wyjścia poza proces, zwykle warto ją wydzielić.

Krok po kroku refaktora (powtarzalny wzorzec)

1. Wybierz jeden seam: jedną zewnętrzną zależność, którą kod aktualnie newuje lub wywołuje bezpośrednio.
2. Wyciągnij interfejs (albo prosty kontrakt): zdefiniuj zachowanie, którego naprawdę potrzebujesz (zwykle 1–3 metody). Trzymaj go małym.
3. Utwórz realną implementację: opakuj istniejącą konkretną zależność za tym interfejsem.
4. Wstrzyknij ją: przekaż interfejs przez konstruktor lub argumenty funkcji. Wybierz najprostsze pasujące rozwiązanie.
5. Zaktualizuj okablowanie produkcyjne: stwórz realną implementację w jednym miejscu (punkt wejścia aplikacji, fabryka, composition root) i przekaż ją.
6. Zaktualizuj testy: zamień realną implementację na fake/stub/mock, który zwraca przewidywalne wartości.

To podejście sprawia, że każda zmiana jest łatwo przeglądalna i pozwala zatrzymać się po dowolnym kroku bez łamania systemu.

Zachowanie spójności modułów podczas wstrzykiwania zależności

DI łatwo może zmienić kod w „wszystko zależy od wszystkiego”, jeśli wstrzykujesz zbyt wiele.

Dobra zasada: wstrzykuj możliwości, nie szczegóły. Na przykład wstrzyknij Clock zamiast „SystemTime + TimeZoneResolver + NtpClient”. Jeśli klasa potrzebuje pięciu niepowiązanych serwisów, prawdopodobnie robi za dużo — rozważ podział.

Unikaj też przekazywania zależności przez wiele warstw „na zapas”. Wstrzykuj tylko tam, gdzie są używane; centralizuj okablowanie w jednym miejscu.

Uwaga o DI przy generowaniu/skafoldowaniu aplikacji

Jeśli korzystasz z generatora kodu lub workflow do szybkiego spin-upu funkcji, DI staje się jeszcze cenniejsze, bo zachowuje strukturę w miarę wzrostu projektu. Na przykład, gdy zespoły używają Koder.ai do tworzenia frontendów React, serwisów Go i backendów opartych na PostgreSQL z opisów w czacie, jasny composition root i interfejsy przyjazne DI pomagają, by wygenerowany kod pozostał łatwy do testowania, refaktoryzacji i zmiany integracji (e-mail, płatności, storage) bez przepisywania logiki biznesowej.

Zasada pozostaje ta sama: trzymaj tworzenie obiektów i środowiskowe okablowanie na granicy, a logikę biznesową skupioną na zachowaniu.

Co mierzyć po zmianie

Powinieneś móc wskazać konkretne usprawnienia:

• Szybsze testy jednostkowe (mniej czekania na DB/sieć/czas)
• Bardziej izolowane testy (mniej globalnych setupów i współdzielonego stanu)
• Czystsze granice (jasne kontrakty między modułami)
• Łatwiejsze zmiany (podmiana klienta API lub strategii storage bez rozległych edycji)

Jeśli chcesz kolejnego kroku, udokumentuj swój „composition root” i trzymaj go nudnym: jeden plik składający zależności, podczas gdy reszta kodu pozostaje skupiona na zachowaniu.