Rozwijam się w Spring Boot od nieco ponad roku, ale jeszcze nie zrozumiałem korzyści z używania konstruktora Autowired i zastanawiałem się, czy ktoś mógłby wyjaśnij mi to i co byłoby uważane za najlepszą praktykę.
Powiedzmy, że mam fasolkę w następujący sposób
@Component public class MyBean { void doSomeStuff() { } } I mam usługa, która ma zależność od tego komponentu bean
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Dla mnie najprostszym sposobem na wprowadzenie zależności w tej klasie byłoby po prostu dodanie adnotacji do zmiennej @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Ale są inne miejsca online (a także inni programiści z mojego zespołu), którzy preferują takie podejście:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Dla mnie użycie takiego konstruktora jest po prostu zbędnym kodem. Automatyczne podłączanie fasoli jest znacznie prostsze i prostsze niż to, co wydaje mi się kodem standardowym.
Komentarze
Odpowiedź
Używasz prawdziwy konstruktor z tych samych powodów, dla których używasz publicznych metod pobierających i ustawiających zamiast upubliczniać prywatne zmienne.
Niektóre przykłady z życia wzięte: telefony komórkowe nie są dozwolone w bezpiecznych, wrażliwych na informacje lokalizacjach fizycznych. Wszelka komunikacja z tą bezpieczną lokalizacją musi odbywać się za pośrednictwem bezpiecznie ustanowionego, kontrolowanego i zaszyfrowanego protokołu komunikacyjnego, a nie potajemnie przez niemonitorowany i niekontrolowany fałszywy kanał komunikacyjny.
Na koncercie nie pozwalasz ludziom przerzucać rzeczy przez płot komuś, kto jest już na stadionie. Wszystko, co wchodzi i wychodzi, musi przejść przez bramę.
Jeśli to wszystko w przykładowym kodzie, to wygląda na to, że niepotrzebnie rozwlekły schemat. Ale często robimy inne rzeczy w konstruktorze oprócz ustawiania zmienne prywatne, takie jak walidacja. W wielu językach programowania zmiana sposobu wykonywania tej czynności po fakcie jest zmianą binarną, więc podanie konstruktora z góry może być rozsądnym krokiem.
Wreszcie, klasa powinna być w stanie działać niezależnie od wstrzyknięcia zależności. Jeśli umieścisz adnotację na prywatnym składniku, ale nie uwzględnisz konstruktora , zasadniczo ściśle związałeś tę klasę z kontenerem DI, a klasa nie będzie działać bez niego.
Komentarze
- " Na koncercie nie ' nie zezwalasz ludziom na rzucanie rzeczy przez płot komuś, kto ' jest już na stadionie m. Wszystko, co wchodzi lub wychodzi, musi przejść przez bramę. " Ale nie '. Nie rozumiem, w jaki sposób użycie konstruktora zwiększa bezpieczeństwo automatycznego okablowania? Gdyby nie było wymagań dotyczących konstruktora (takich jak walidacja), czy użycie konstruktora przyniosłoby jakąkolwiek korzyść?
- Umożliwisz później dodanie walidacji bez naruszania zgodności binarnej.
- Ponadto pamiętaj, że prywatni członkowie powinni naprawdę pozostać prywatni. To ' to właściwie cały sens posiadania prywatnych członków.
- Chodzi o to, aby projektować dobre praktyki zgodne z @Autowire. Posiadanie konstruktorów jest NAJBARDZIEJ naturalną rzeczą w OOP. Wręcz przeciwnie, (to, co nazywasz prostym i prostszym) jest trochę przerażające. Usunięcie konstruktorów nie daje żadnych realnych korzyści, ' nie ma w tym żadnej prostoty. Konstruktory należą do najprostszych metod w OOP.Same w sobie mają zwykle bardzo małą złożoność, która warta jest implementacji magii Spring IoC
- Ze względu na to, co ' jest warte, Java zwykle jest i tak bardzo rozwlekły język. Jeśli ' chcesz ujarzmić część tej gadatliwości, wyeliminowanie konstruktorów prawdopodobnie nie przyniesie większego uszczerbku.
To me, using a constructor like that is simply redundant code. Autowiring the bean is much simpler and straightforward than what appears to me to be boilerplate code.i czy nie martwisz się o magię wstrzykiwania ziarna do zmiennej instace, która jest prywatna i nie ma metody ustawiającej? Nie martwisz się ogromnym długiem technicznym, jaki generuje to u Ciebie, Twoich współpracowników? Czy nie obawiasz się zbytniego przekazywania magicznego paradygmatu ' Spring zamiast dobrych praktyk projektowania?