Mă dezvolt în Spring Boot de puțin peste un an, dar încă nu am înțeles avantajele utilizării unui constructor Autowired și mă întrebam dacă cineva ar putea explică-mi acest lucru și ce ar fi considerat cea mai bună practică.
Să spunem că am un bob după cum urmează
@Component public class MyBean { void doSomeStuff() { } } Și am un serviciu care are o dependență de acel bean
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Pentru mine, cel mai simplu mod de a injecta dependența din această clasă ar fi să adnotați pur și simplu variabila cu @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Dar există și alte locuri online (și, de asemenea, alți dezvoltatori din echipa mea) care favorizează ceva de genul acestei abordări:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Pentru mine, utilizarea unui astfel de constructor este pur și simplu un cod redundant. Cablarea automată a bobului este mult mai simplă și simplă decât ceea ce mi se pare a fi codul boilerplate.
Comentarii
Răspuns
Folosiți un constructor real din aceleași motive pentru care utilizați seturi și setări publice în loc să faceți publice variabilele private.
Unele exemple din viața reală: telefoanele mobile nu sunt permise în locații fizice sigure, sensibile la informații. Orice comunicare cu acea locație sigură trebuie să aibă loc printr-un protocol de comunicații stabilite, controlate și criptate în siguranță, nu subrept de un canal de comunicații necinstit ne-monitorizat și necontrolat.
La un concert, nu permiteți oamenilor să aruncă lucrurile peste gard cuiva care este deja pe stadion. Orice lucru care intră sau iese trebuie să treacă printr-o poartă.
Dacă asta este tot ce există în exemplul de cod, atunci apare ca o boilerplată inutilă. Dar în mod frecvent facem alte lucruri în constructor în afară de setare variabile private, cum ar fi validarea. În multe limbaje de programare, schimbarea modului în care faceți acest lucru este o modificare binară de rupere, deci furnizarea constructorului în față poate fi un pas sensibil.
În cele din urmă, clasa ar trebui să poată funcționa independent de injecția de dependență. Dacă puneți o adnotare pe un membru privat, dar nu reușiți să includeți un constructor , ați „legat în mod strâns acea clasă de containerul DI, iar clasa nu va funcționa fără ea.
Comentarii
- " La un concert, nu ' nu permiteți oamenilor să arunce lucruri peste gard cuiva care ' s deja în stadiu m. Orice lucru care intră sau iese trebuie să treacă printr-o poartă. " Dar nu ' nu văd cum utilizarea unui constructor face cablarea automată mai sigură? Dacă nu ar exista cerințe de constructor (cum ar fi validarea), atunci ar fi de vreun beneficiu să folosiți un constructor?
- Faceți posibilă adăugarea validării ulterior fără a rupe compatibilitatea binară.
- De asemenea, , rețineți că membrii privați ar trebui să rămână cu adevărat privați. Că ' este cam tot ceea ce înseamnă a avea membri privați.
- Întregul punct este de a permite bune practici de proiectare compatibile cu @Autowire. A avea constructori este cel mai natural lucru din POO. Dimpotrivă, (ceea ce voi numiți simplu și simplu) este cam înfricoșător. Nu există beneficii reale la eliminarea constructorilor, nu există ' deloc simplitate. Constructorii sunt printre cele mai simple metode din POO.Per se, de obicei au foarte puțină complexitate care merită să implementeze magia IoC de primăvară
- Pentru ceea ce merită ', Java tinde să fie un limbaj foarte oricum oricum. Dacă ' căutați să îmblânziți o parte din acea verbozitate, eliminarea constructorilor nu este susceptibilă de a face o mare mizerie.
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 nu sunteți îngrijorat de magia injectării unui bob într-o variabilă instace care este privată și nu are setter? Nu vă îngrijorează imensa datorie tehnică pe care aceasta o generează asupra dvs., colegilor dvs. de muncă? Nu sunteți îngrijorat de reluarea prea multă a paradigmei magice a primăverii ' în loc de proiectarea bunelor practici?