[billy0o]

Spotkałem się wielokrotnie z opinią, że używanie adnotacji @Inject do prywatnych właściwości klas to anty-pattern, że lepiej używać wstrzykiwanie do konstruktora. Szukam poważniejszych argumentów niż "dobra praktyka". Z doświadczenia wiem, że tworzenie konstruktora tylko po to, żeby wstrzyknąć zależności to boilerplate. Jeden z argumentów który wydaje się sensowny to wstrzykiwanie mocków w unit testach, tylko, że mockito radzi sobie z adnotacją @Inject więc do mnie ten argument nie trafia.
Zapraszam do dyskusji

#java #programowanie

[kszych]

@billy0o: spróbuj wstrzyknąć do testowanej klasy listę mocków (strategii) bez settera/konstruktora ( ͡° ͜ʖ ͡°)

[billy0o]

@kszych: mockito sobie z tym radzi bez problemow, przeciez o tym pisalem.

[fegwegw]

Jeden z argumentów który wydaje się sensowny to wstrzykiwanie mocków w unit testach

@billy0o: To jest koronny argument. Poza tym dochodzą takie problemy jak np. łatwość utraty kontroli nad zależnościami (pff, dodam kolejny field, co może pojść źle?), brak możliwości injectowania pól finalnych (to pewnie zależy od kontenera), związanie z frameworkiem kontenera, i pewnie jeszcze kilka innych, pomniejszych minusów.

tylko, że mockito radzi sobie z adnotacją @Inject więc do mnie ten

[billy0o]

@fegwegw: no z tym dodawaniem kolejnych zaleznosci to troche racja ale konstruktor jakos tez przed tym nie powstrzymuje. Nie raz nie dwa widziałem konstruktor z 5+ argumentami. Więc taka troche "dobra praktyka" w złym tego słowa znaczeniu. Bo generuje boilerplate dla tych co znają SOLID. A raczej tym co nie znają nie przeszkodzi w tworzeniu god objects.

Co innego unit testy ( ͡° ͜ʖ ͡°)

że coś

[ppawel]

@billy0o: Uparcie taki wzorzec forsuje np. IntelliJ, w aktualnych wersjach domyślnie oznaczając wstrzykiwanie przez pola jako warning.
Głównym plusem wstrzykiwania przez konstruktor jest to, że trzyma programistę za mordę:
1) skoro jakieś powiązanie jest wymagane to pojawi się błąd już na etapie kompilacji a nie dopiero wstawania kontekstu
2) konstruktor z milionem parametrów wygląda źle - dużo gorzej niż nawet kilka ekranów pól z @Autowired, więc dodanie nowej zależności zmusza

[billy0o]

@ppawel: no i zajebiscie 2 solidne argumenty, props

[kszych]

@billy0o: nie radzi sobie, możesz uzyć @InjectMocks i wstrzyknąć pola, ale nie zainicjalizujesz kolekcji przygotowaną wcześniej listą elementów (mocków)

http://stackoverflow.com/questions/42351117/mockito-injecting-a-list-of-mocks

[billy0o]

@kszych: @ppawel: @fegwegw: dobra, przekonaliscie mnie. Dzięki chłopaki prawilne z was mordeczki ( ͡º ͜ʖ͡º)

[fegwegw]

Z drugiej strony fakt ze część libów do mockowania (wszystkie poza Mockito?) sobie z czyms nie radzi nie oznacza ze nie powinno się tego robić. Więc argument-przepychanka.

@billy0o: nie chodzi o to, że sobie nie radzą, chodzi o to, że po prostu nie powinno się niektórych rzeczy używać. Np. spy mockitowy nie jest zbyt szczęśliwym rozwiązaniem.

Nie rozumiem tego argumentu szczerze mówiąc. Chodzi o klasy abstrakcyjne?

@billy0o: chodzi o pola

[Enofod]

@billy0o: Field injection powoduje, że uzależniasz się od frameworka, żeby Twoja aplikacja działała. Nie jest już zwykłą aplikacją javową. Głównym założeniem springa, jak go w 2003 roku tworzono było, żeby był nieinwazyjny.

Przez to, że Spring przez ostatnie lata bardzo szybko sie rozwijał, to się zrobił troszke chaos, dlatego field injection jest nadal wspierane, chociaż w oficjalnej dokumentacji widnieje taki zapis:

DI exists in two major variants, Constructor-based dependency injection

[billy0o]

@Enofod: No ale czasmi trzeb uzywac setter injection np dla zaleznosci niewymaganych. Czy da się to inaczej rozwiązać?

[MagisterPigularz]

@billy0o: chyba to jest głównym założeniem tego że powinno być możliwe wstrzykiwanie w 2 wariantach. Setera możesz potem użyć w teście i mozews testować.