Jeg har utviklet oss i Spring Boot i litt over et år, men har ennå ikke forstått fordelene ved å bruke en Autowired-konstruktør, og jeg lurte på om noen kunne forklar meg dette og hva som vil bli ansett som best praksis.
La oss si at jeg har en bønne som følger
@Component public class MyBean { void doSomeStuff() { } } Og jeg har en tjeneste som har en avhengighet av den bønnen
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } For meg vil den enkleste måten å injisere avhengigheten i denne klassen være å bare kommentere variabelen med @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Men det er andre steder på nettet (og også andre utviklere på teamet mitt) som favoriserer noe som denne tilnærmingen:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } For meg er det bare overflødig å bruke en konstruktør som den. Autotilkobling av bønnen er mye enklere og grei enn det som for meg ser ut som en kjeleplatekode.
Kommentarer
Svar
Du bruker en ekte konstruktør av samme grunner som at du bruker offentlige getters og settere i stedet for å gjøre private variabler offentlige.
Noen virkelige eksempler: mobiltelefoner er ikke tillatt på sikre, informasjonsfølsomme fysiske steder. Enhver kommunikasjon med det sikre stedet må skje gjennom en sikkert etablert, kontrollert og kryptert kommunikasjonsprotokoll, ikke skjult av en ikke-overvåket og ukontrollert useriøs kommunikasjonskanal.
På en konsert tillater du ikke folk å kaste ting over gjerdet til noen som allerede er på stadion. Alt som kommer inn eller ut må gå gjennom en port.
Hvis det bare er kodeeksemplet ditt, ser det ut som unødvendig ordentlig kokeplate. Men ofte gjør vi andre ting i konstruktøren i tillegg til å sette private variabler, som validering. I mange programmeringsspråk er det en binær brytningsendring å endre måten du gjør dette på, så å gi konstruktøren foran kan være et fornuftig skritt.
Til slutt skal klassen kunne fungere uavhengig av avhengighetsinjeksjonen. Hvis du legger inn en kommentar til et privat medlem, men ikke klarer å inkludere en konstruktør , du har i det vesentlige bundet den klassen til DI-beholderen, og klassen vil ikke fungere uten den.
Kommentarer
- " På en konsert tillater du ikke ' t folk kan kaste ting over gjerdet til noen som ' er allerede på stadion m. Alt som kommer inn eller ut må gå gjennom en gate. " Men jeg ser ikke ' hvordan bruken av en konstruktør gjør autolederen sikrere? Hvis det ikke var noen konstruktorkrav (som validering), ville det ha noen fordel å bruke en konstruktør?
- Du gjør det mulig å legge til validering senere uten å bryte binær kompatibilitet.
- Også , vær oppmerksom på at private medlemmer virkelig skal være private. At ' er ganske hele poenget med å ha private medlemmer.
- Hele poenget er å tillate design god praksis som er kompatibel med @Autowire. Å ha konstruktører er den MEST naturlige tingen i OOP. Tvert imot, (det du kaller rett og greit) er ganske skummelt. Det er ingen reelle fordeler med å fjerne konstruktører, det er ' det er ingen enkelhet i det hele tatt. Konstruktører er blant de mest enkle metodene i OOP.I seg selv har de vanligvis veldig lite kompleksitet som er verdt å implementere magien til Spring IoC
- For det det ' er verdt, pleier Java å være en veldig detaljert språk uansett. Hvis du ' ønsker å temme noe av det ordet, vil det sannsynligvis ikke gjøre mye av å eliminere konstruktører.
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.og er du ikke bekymret for magien ved å injisere en bønne i en instace-variabel som er privat og uten setter? Er du ikke bekymret for den enorme tekniske gjelden dette genererer deg, dine kolleger? Er du ikke bekymret for å videresende for mye på vårens ' magiske paradigme i stedet for å utforme god praksis?