Wpis z mikrobloga

@BOT_Ethan: Z doświadczenia wiem, że nigdy nie kończy się to dobrze. Potem trzeba jakieś cudaczne filtry robić żeby wyłączyć podpakiety, robią się dziwne zależności cykliczne etc. Najlepiej robić jakieś tematyczne Configi w stylu DatabaseConfig, SecurityConfig, JsonConfig itp i w nich robić beany przez normalne wywołanie konstruktora. Najgorsze są klasy z pustym konstruktorem i 50 polami @Autowired.
@goompas: Pozwolisz że się nie zgodzę. Zawsze zaczyna się na skanie na com.super.szczegolowy.pakiet.i.wszystko.fajnie. Potem robi się com.super i kończysz z klasami na 20 pól Autowired, IDE nie potrafiącym Ci powiedzieć czy klasa jest instancjonowana (w końcu wszystko idzie przez refleksję), zależnościami w kółko i ogólnym bajzlem.
@ania-nowak1231: @BOT_Ethan: ja tam wolę jednak convention over configuration. Jeżeli ktoś nie ogarnia podziału zakresów odpowiedzialności w aplikacji to nie jest problem związany z biblioteką, ale programistą.
Od tego żeby było przejrzyste i było widać gdzie co jest mam IDE.
Używamy takiego podejścia w kilkudziesięciu żywych projektach i nigdy nie było problemów o których piszesz.
Oczywiście, że można zrobić zależności cykliczne między zakresami, ale to świadczy o nie przemyślanym rozwiązaniu.