Olen kehittänyt Spring Bootia jo yli vuoden, mutta en ole vielä ymmärtänyt Autowired-konstruktorin käytön etuja ja mietin, pystyisikö joku selitä tämä minulle ja mikä olisi parasta käytäntöä.
Oletetaan, että minulla on papu seuraavasti
@Component public class MyBean { void doSomeStuff() { } } Ja minulla on palvelu, joka on riippuvainen kyseisestä pavusta
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Minulle yksinkertaisin tapa lisätä riippuvuus tähän luokkaan olisi yksinkertaisesti merkitä muuttuja @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Mutta verkossa on muitakin paikkoja (ja myös muita tiimini kehittäjiä), jotka suosivat jotain tällaista lähestymistapaa:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Minulle tällaisen konstruktorin käyttäminen on yksinkertaisesti turhaa koodia. Pavun automaattinen lataaminen on paljon yksinkertaisempaa ja suoraviivaisempaa kuin mitä minusta näyttää olevan kattilakoodi.
Kommentit
Vastaa
Käytät todellinen rakentaja samoista syistä, että käytät julkisia gettereitä ja asetinlaitteita yksityisten muuttujien julkistamisen sijaan.
Joitakin tosielämän esimerkkejä: matkapuhelimia ei sallita turvallisissa, tietoherkissä fyysisissä paikoissa. Kaiken yhteydenpidon suojatun sijainnin kanssa on tapahduttava turvallisesti perustetun, hallitun ja salatun tietoliikenneprotokollan kautta, jota valvomaton ja hallitsematon roistovaltiokanava ei voi salaa.
Konsertissa et salli ihmisten heittää asiat aidan yli jollekin, joka on jo stadionilla. Kaikkien sisään tai ulos tulevien on mentävä portin kautta.
Jos koodiesimerkissäsi on kaikki, niin se näyttää tarpeettoman tarkalta kattilalta. Mutta usein teemme konstruktorissa muita asioita asetusten lisäksi yksityiset muuttujat, kuten validointi. Monissa ohjelmointikielissä tämän tekemisen muuttaminen tosiasian jälkeen on binaarinen rikkominen, joten rakentajan tarjoaminen eteenpäin voi olla järkevä askel.
Lopuksi luokan pitäisi pystyä toimimaan riippumattomuusinjektiosta riippumatta. Jos laitat merkinnän yksityiselle jäsenelle, mutta et sisällytä konstruktoria , olet olennaisesti tiukasti sitonut kyseisen luokan DI-säiliöön, eikä luokka toimi ilman sitä.
Kommentit
- " Konsertissa et salli ' et salli ihmisten heittää esineitä aidan yli jollekin ' s on jo stadionilla m. Kaikkien sisään tai ulos tulevien on mentävä portin läpi. " Mutta en ' näe, kuinka rakentajan käyttäminen tekee automaattisen kaapeloinnin turvallisemmaksi? Jos konstruktorivaatimuksia (kuten validointia) ei ollut, onko konstruktorin käytöstä mitään hyötyä?
- Voit lisätä validoinnin myöhemmin rikkomatta binääristä yhteensopivuutta.
- Myös , huomaa, että yksityisten jäsenten tulisi todella pysyä yksityisinä. Tämä ' on tavallaan yksityisten jäsenten koko asia.
- Koko ajatus on sallia @Autowiren kanssa yhteensopivat suunnittelun hyvät käytännöt. Rakentajien ottaminen on OOP: n luonnollisinta. Päinvastoin, (mitä kutsutte suoraviivaiseksi ja yksinkertaisemmaksi), on melko pelottava. Rakentajien poistamisesta ei ole todellisia etuja, siinä ei ole lainkaan yksinkertaisuutta '. Rakentajat ovat yksinkertaisimpia menetelmiä OOP: ssa.Sinänsä niillä on yleensä hyvin vähän monimutkaisuutta, joka kannattaa toteuttaa kevään IoC: n taika.
- Java
on sen arvoinen hyvin sanallinen kieli joka tapauksessa. Jos ' yrität kesyttää osaa siitä sanattomuudesta, rakentajien poistaminen ei todennäköisesti aiheuta suurta haittaa.
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.ja etkö ole huolissasi taivasta pistää papu yksityismuuttujaan, jossa ei ole asetinta? Etkö ole huolissasi siitä suuresta teknisestä velasta, jonka tämä tuottaa sinulle, työtovereillesi? Etkö ole huolissasi siitä, että välität liikaa kevään ' maagista paradigmaa hyvien käytäntöjen suunnittelun sijaan?