W tym tygodniu zastanawiałem się nad użyciem frameworku Typhoon do wstrzykiwania zależności. Rozumiem, że rozdzielenie konstrukcji obiektów jest korzystne w przypadku zastępowania dowolnych komponentów próbkami podczas testów jednostkowych i do tej pory widziałem same korzyści.
Ale nie mogę przestać myśleć, że gdzie wcześniej miałem ogromną klasę kontrolera widoku, która miała dziesiątki importów nagłówków, teraz mam ogromną klasę fabryki, która ma dziesiątki importów nagłówków. Czy powinienem unikać masowej klasy fabrycznej?
6
Za dziesięć lat spodziewam się, że DI przejmie listę krytyków od Singletona, ale tym razem z dobrych powodów. Ma kilka dobrych zastosowań, ale sugeruję, aby bardzo uważnie oceniać wpływ.
—
Balog Pal
Nie sądzę, że wstrzykiwanie zależności jest sposobem na zmniejszenie złożoności, ale sposobem na uniknięcie ukrytych zależności (użycie symboli globalnych / zmiennych wolnych) na rzecz wyraźnych zależności (użycie parametrów jawnych / zmiennych powiązanych). Tak więc złożoność wciąż istnieje, ale jesteś zmuszony sobie z tym poradzić, ponieważ wyrażasz to wyraźnie w podpisach metod / konstruktorów.
—
Giorgio
Zauważ, że prawie każdy system do porządkowania kodu można opisać jako „przenoszenie złożoności gdzie indziej”. Nie chodzi o usuwanie złożoności, ale o organizowanie jej w najbardziej logiczny i użyteczny sposób.
Jeśli musisz zaimportować 50 nagłówków, musisz to gdzieś zrobić. DI pomaga w łatwiejszym sposobie testowania jednostkowego kodu.
—
7овић
Czy mówisz, że teraz kontroler koncentruje się na kontrolowaniu, a fabryka importu nagłówków koncentruje się na imporcie nagłówków? Jak to może być źle, niezależnie od tego, czy używasz frameworka DI, czy nie?
—
pdr