Jeg har udviklet mig i Spring Boot i godt et år, men har endnu ikke forstået fordelene ved at bruge en Autowired-konstruktør, og jeg spekulerede på, om nogen kunne forklar mig dette, og hvad der ville blive betragtet som bedste praksis.
Lad os sige, at jeg har en bønne som følger
@Component public class MyBean { void doSomeStuff() { } } Og jeg har en tjeneste, der har en afhængighed af den bønne
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } For mig er den enkleste måde at injicere afhængigheden i denne klasse på blot at kommentere variablen med @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Men der er andre steder online (og også andre udviklere på mit team), der foretrækker noget som denne tilgang:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } For mig er det simpelthen overflødig at bruge en sådan konstruktør. Autotrådning af bønnen er meget enklere og ligetil, end hvad der synes for mig at være kedelpladekode.
Kommentarer
Svar
Du bruger en reelle konstruktører af de samme grunde, som at du bruger offentlige getters og settere i stedet for at offentliggøre private variabler.
Nogle eksempler i det virkelige liv: mobiltelefoner er ikke tilladt på sikre, informationsfølsomme fysiske placeringer. Enhver kommunikation med den sikre placering skal finde sted gennem en sikkert etableret, kontrolleret og krypteret kommunikationsprotokol, ikke skjult af en ikke-overvåget og ukontrolleret slyngelskommunikationskanal.
Ved en koncert tillader du ikke folk at smid ting over hegnet til nogen, der allerede er på stadion. Alt, der kommer ind eller ud, skal gå gennem en port.
Hvis det hele er til dit kodeeksempel, ser det ud til at være unødvendigt detaljeret kogeplade. Men ofte gør vi andre ting i konstruktøren ud over at indstille private variabler, som validering. I mange programmeringssprog er det en binær brydningsændring, at ændre den måde, du gør dette på. så det at give konstruktøren foran kan være et fornuftigt skridt.
Endelig skal klassen kunne fungere uafhængigt af afhængighedsinjektionen. Hvis du lægger en kommentar til et privat medlem, men undlader at inkludere en konstruktør , du “har i det væsentlige tæt bundet den klasse til DI-beholderen, og klassen vil ikke arbejde uden den.
Kommentarer
- " Ved en koncert tillader du ikke ' t folk kan kaste ting over hegnet til nogen, der ' er allerede i stadion m. Alt, der kommer ind eller ud, skal gå gennem en gate. " Men jeg kan ikke ' ikke se, hvordan brugen af en konstruktør gør autoledning mere sikker? Hvis der ikke var nogen konstruktorkrav (som validering), ville det være til nogen fordel at bruge en konstruktør?
- Du gør det muligt at tilføje validering senere uden at bryde binær kompatibilitet.
- Også , bemærk, at private medlemmer virkelig skal forblive private. At ' er lidt hele pointen med at have private medlemmer.
- Hele pointen er at tillade god praksis for design, der er kompatibel med @Autowire. At have konstruktører er den MEST naturlige ting i OOP. Tværtimod, (hvad du kalder ligetil og enklere) er lidt skræmmende. Der er ingen reelle fordele ved at fjerne konstruktører, der er ' overhovedet ingen enkelhed i det. Konstruktører er blandt de mest enkle metoder i OOP.I og for sig har de normalt meget lidt kompleksitet, der er værd at implementere magien i Spring IoC
- For hvad det ' er værd, har Java en tendens til at være en meget detaljeret sprog alligevel. Hvis du ' søger at tæmme noget af denne detaljerethed, vil det sandsynligvis ikke være meget at fjerne konstruktioner ved at fjerne 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 at injicere en bønne i en instace-variabel, der er privat og uden setter? Er du ikke bekymret for den enorme tekniske gæld, som dette genererer dig, dine kolleger? Er du ikke bekymret for at videresende for meget på Spring ' s magiske paradigme i stedet for at designe god praksis?