Vyvíjím se v Spring Boot jen něco málo přes rok, ale zatím jsem nepochopil výhody použití konstruktoru Autowired a přemýšlel jsem, jestli by někdo mohl vysvětlete mi to a co by bylo považováno za osvědčený postup.
Řekněme, že mám fazole takto
@Component public class MyBean { void doSomeStuff() { } } A mám služba, která má závislost na tomto fazole
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Pro mě je nejjednodušší způsob vložení závislosti v této třídě jednoduše anotovat proměnnou pomocí @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Existují však i další místa online (a také další vývojáři v mém týmu), kteří upřednostňují něco jako tento přístup:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Pro mě je použití takového konstruktoru jednoduše nadbytečný kód. Autowiring fazole je mnohem jednodušší a přímočarější než to, co se mi zdá být standardním kódem.
Komentáře
Existují nějaké zdroje týkající se správných návrhových postupů vztahujících se k této diskusi, které můžete doporučit? Mám ' zájem o jejich přečtení.
Odpověď
Používáte skutečný konstruktor ze stejných důvodů, které používáte místo veřejného zveřejňování a nastavování namísto zveřejňování soukromých proměnných.
Některé příklady ze skutečného života: mobilní telefony nejsou povoleny na zabezpečených fyzických místech citlivých na informace. Jakákoli komunikace s tímto zabezpečeným místem musí probíhat prostřednictvím bezpečně zavedeného, kontrolovaného a šifrovaného komunikačního protokolu, nikoli tajně nemonitorovaným a nekontrolovaným nepoctivým komunikačním kanálem.
Na koncertě lidem nedovolíte hodit věci přes plot někomu, kdo už je na stadionu. Cokoli, co přichází nebo odchází, musí projít branou.
Pokud je to vše, co je k vašemu příkladu kódu k dispozici, vypadá to jako zbytečně podrobný typový štítek. V konstruktoru však kromě nastavení často děláme i jiné věci soukromé proměnné, jako je validace. V mnoha programovacích jazycích je změna způsobu, jakým to děláte, faktem binární zlomové změny, takže poskytnutí konstruktoru předem může být rozumným krokem.
Nakonec by třída měla být schopna fungovat nezávisle na injekci závislostí. Pokud vložíte anotaci na soukromého člena, ale nezahrnete konstruktor , jste tuto třídu v podstatě pevně svázáni s kontejnerem DI a třída bez ní nebude fungovat.
Komentáře
- " Na koncertě ' nedovolíte lidem házet věci přes plot někomu, kdo ' již ve stadiónu m. Cokoli, co přichází dovnitř nebo ven, musí projít bránou. " Ale nechápu ', jak použití konstruktoru zvyšuje bezpečnost autowiring? Pokud by neexistovaly žádné požadavky na konstruktor (jako je validace), bylo by užitečné použít konstruktor?
- Umožníte přidat ověření později bez narušení binární kompatibility.
- Také Všimněte si, že soukromí členové by měli skutečně zůstat soukromí. To ' tak trochu znamená mít soukromé členy.
- Celá podstata umožňuje navrhnout osvědčené postupy kompatibilní s @Autowire. Mít konstruktory je NEJPŘÍRODNĚJŠÍ věcí v OOP. Naopak (to, co nazýváte přímočaré a jednodušší) je trochu děsivé. Odstranění konstruktérů nemá žádné skutečné výhody, ' na tom není vůbec žádná jednoduchost. Konstruktory patří mezi nejjednodušší metody v OOP.Per se obvykle mají velmi malou složitost, která stojí za implementaci kouzla jarního IoC
- Kvůli tomu, jak to ' stojí, má Java tendenci být velmi velmi podrobný jazyk. Pokud se ' snažíte některou z těchto výřečností zkrotit, eliminace konstruktérů pravděpodobně nebude mít velký vliv.
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.a nezajímá vás kouzlo vstřikování fazole do proměnné instace, která je soukromá a nemá nastavovač? Neobáváte se obrovského technického dluhu, který pro vás, vaše spolupracovníky, vytváří? Neobáváte se přílišného předávání jarního ' kouzelnického paradigmatu místo toho, abyste navrhovali dobré postupy?